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Abstract 


Analysis  of  raw  memory  dumps  has  become  a  critical  capability  in  digital  forensics 
because  it  gives  insight  into  the  state  of  a  system  that  cannot  be  fully  represented  through 
traditional  disk  analysis.  Interest  in  memory  forensics  has  grown  steadily  in  recent  years, 
with  a  focus  on  the  Microsoft  Windows  operating  systems.  However,  similar  capabilities 
for  Linux  and  Apple  OS  X  have  lagged  by  comparison.  The  volafox  open  source  project 
has  begun  work  on  structured  memory  analysis  for  OS  X.  The  tool  currently  supports  a 
limited  set  of  kernel  structures  to  parse  hardware  information,  system  build  number, 
process  listing,  loaded  kernel  modules,  syscall  table,  and  socket  connections.  This 
research  addresses  one  memory  analysis  deficiency  on  OS  X  by  introducing  a  new 
volafox  module  for  parsing  fide  handles.  When  open  files  are  mapped  to  a  process,  an 
examiner  can  learn  which  resources  the  process  is  accessing  on  disk.  This  listing  is  useful 
for  determining  what  information  may  have  been  the  target  for  exfilitration  or 
modification  on  a  compromised  system.  Comparing  output  of  the  developed  module  and 
the  UNIX  Isof  (list  open  files)  command  on  two  version  of  OS  X  and  two  kernel 
architectures  validates  the  methodology  used  to  extract  file  handle  information. 
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FORENSIC  MEMORY  ANALYSIS  FOR  APPLE  OS  X 


I.  Introduction 

Desktop  and  mobile  eomputing  platforms  are  eentral  to  many  law  enforeement 
and  enterprise  investigations  due  to  their  enormous  eapacity  for  digital  evidenee. 
Identifieation,  individualization,  assoeiation,  and  reeonstruetion  of  sueh  evidenee  are  all 
steps  of  the  forensic  process  (Inman  &  Rudin,  2002).  Professionals  rely  on  both  teehnieal 
expertise  and  appropriate  tools  when  applying  these  steps  to  digital  sourees.  Beeause  an 
examiner  eannot  always  antieipate  the  platforms  eneountered  during  the  eourse  of  an 
investigation,  he  or  she  must  be  prepared  to  deal  with  any  of  them.  Tools  for  data 
aequisition  and  analysis  are  therefore  required  across  a  breadth  of  common  endpoint 
devices  in  order  to  assure  needed  flexibility,  Apple’s  OS  X  among  them. 

Apple  currently  holds  the  number  three  position  in  PC  manufacturing  (Schonfeld, 
2012),  with  its  OS  X  operating  system  representing  about  10%  domestic  market  share 
(Donnini,  2012)  and  6%  globally  (Net  Applications,  2012).  While  this  accounts  for  a 
small  minority  when  compared  with  Microsoft  Windows,  OS  X  has  become  the  operating 
system  of  preference  for  many  individuals.  As  a  result,  it  cannot  be  ignored  as  a  possible 
target  during  forensic  investigation. 

Forensic  memory  analysis  has  become  a  critical  capability  in  digital  forensics 
because  it  allows  insight  into  the  state  of  a  system  that  cannot  be  fully  represented 
through  traditional  disk  analysis.  From  an  investigative  standpoint,  computer  memory 
may  be  the  only  source  of  data  capable  of  revealing  the  use  or  misuse  of  computer  at  time 
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of  seizure.  Additionally,  it  may  hold  the  sole  evidenee  of  malware  or  other  eompromise 
influeneing  the  eonelusions  of  the  examiner.  Interest  in  memory  forensies  has  grown 
steadily  in  reeent  years,  with  a  foeus  on  the  Mierosoft  Windows  operating  systems 
(Cohen  &  Collett,  2008).  However,  similar  eapabilities  for  platforms  sueh  as  OS  X  have 
lagged  by  eomparison. 

Memory  analysis  depends  on  eapabilities  for  RAM  aequisition  and  tools  for 
abstraeting  information  from  raw  memory.  Though  tools  exist  to  eapture  memory  on  OS 
X  (Seetion  2.4),  the  sole  projeet  foeusing  on  struetured  data  analysis  (Lee,  2011)  is 
immature  by  eomparison  to  its  eounterpart  for  Windows  and  Linux  (Volatile  Systems, 
2012).  This  leaves  primarily  eontext-free  options  available  to  the  forensic  examiner,  such 
as  string  searches  and  file  carving.  The  challenge  is  to  perform  better  than  context-free 
memory  analysis  so  ultimately  tools  can  be  developed  to  replace  more  invasive  incident 
response  methods  for  determining  the  state  of  a  running  system.  This  research  addresses 
one  component  in  the  suite  of  data  collected  during  live  response:  a  list  of  file  handles 
associated  with  running  processes. 

When  open  files  are  mapped  to  a  process,  an  examiner  can  learn  which  resources 
the  process  is  accessing  on  disk.  This  listing  is  useful  in  determining  what  information 
may  have  been  the  target  for  exfilitration  or  modification  on  a  compromised  system. 
Handles  may  also  help  identify  a  suspicious  process  when  unexpected  file  access  or 
modifications  are  observed.  For  example,  malware  masquerading  as  an  innocuous 
executable  while  editing  log  files  to  its  cover  tracks.  Because  open  files  can  help 
characterize  process  activity  and  highlight  misuse  of  a  computer  during  an  investigation, 
it  is  desirable  to  recover  this  information  from  a  memory  capture. 
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1.1  Research  Objectives  and  Assumptions 

The  goal  of  this  research  is  to  implement  and  document  a  capability  for  parsing 
fde  handles  from  raw  memory  captured  on  OS  X.  Two  objectives  are  derived  to  support 
this  goal.  First,  perform  design  recovery  of  the  kernel  data  structures  responsible  for 
handling  open  files.  Second,  develop  a  flexible  process  for  programmatically  handling 
structures  defined  for  different  kernel  architectures  and  operating  system  versions.  This 
necessitates  extensible  software  design  resilient  to  changes  in  future  versions  of  OS  X. 
Assumptions  related  to  achieving  the  research  goal  include: 

1.  A  method  already  exists  for  copying  physical  memory  to  file  in  a  forensically 
sound  manner. 

2.  Because  analysis  is  always  performed  on  a  forensic  duplicate  of  imaged  memory, 
the  tool  developed  is  not  guaranteed  nor  required  to  ensure  data  integrity. 

3.  Prior  work  can  determine  the  addresses  associated  with  key  kernel  symbols  and 
perform  virtual  to  physical  address  translation. 

4.  Direct  validation  of  tool  output  is  not  possible  and  must  therefore  be  compared 
with  approximate  data,  the  acquisition  of  which  alters  the  state  of  memory. 

5.  Code  defining  the  parsed  kernel  data  structures  is  open  source. 

6.  The  set  of  architectures  under  consideration  is  limited  to  Intel  1386  and  x86_64. 

7.  The  set  of  OS  X  operating  systems  under  consideration  is  limited  to  10.6.x  Snow 
Leopard  and  10.7.x  Lion. 

8.  The  set  of  handle  types  supported  by  the  implementation  is  not  comprehensive. 
The  first  two  assumptions  leverage  existing  work  described  in  Sections  2.4  and  2.5.2 
respectively.  Validation  challenges  are  addressed  in  Section  4.1.  Design  assumptions  and 
emergent  research  limitations  are  discussed  throughout  Chapter  3  and  formally  classified 
in  Section  4.1.2. 
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1.2  Methodological  Approach 

The  open  source  volafox  project  (Lee,  2011)  has  begun  the  work  of  analyzing  raw 
memory  dumped  on  OS  X  with  modules  for  parsing  hardware  information,  system  build 
number,  process  listing,  loaded  kernel  modules,  syscall  table,  and  socket  connections. 
One  omission  in  the  existing  volafox  feature  set  is  an  ability  to  list  file  handles.  This 
research  presents  the  memory  analysis  methodology  required  to  extract  file  handles  in  use 
by  each  process,  and  demonstrates  its  application  through  a  new  volafox  module.  The 
research  module  outputs  handle  information  corresponding  to  process  name,  PID,  file 
descriptor,  access  mode,  handle  type,  size/offset,  catalog  node  ID,  and  name.  Supported 
handles  include  regular  files,  directories,  symbolic  links,  character  special  files,  memory- 
mapped  fdes  associated  with  the  process  executable  and  its  current  working  directory. 

Chapter  3  describes  methodology  for  implementing  the  new  file  handles  module. 
Software  design  requirements  and  constraints  are  listed  along  with  a  format  specification 
for  the  information  displayed  to  the  user.  Next,  design  recovery  of  key  kernel  data 
structures  is  presented.  The  relevant  members  and  relationships  of  36  xnu  kernel 
structures  are  used  to  parse  the  required  handle  information.  Package  organization,  key 
objects,  and  functions  from  the  existing  volafox  source  code  are  then  described.  Object- 
oriented  design  of  the  new  fide  handles  module  is  depicted  using  UML  and  a  description 
of  the  data  structure  template  development  process  is  presented.  Chapter  3  closes  with  a 
discussion  of  outstanding  implementation  issues.  Results  of  the  new  module  are  validated 
against  the  UNIX  command-line  tool  Isof  (list  open  files)  in  Chapter  4.  Versions  10.6 
Snow  Leopard  and  10.7  Lion  of  the  OS  X  operating  system  for  both  32  and  64-bit  kernels 
are  the  tested  configurations. 
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1,3  Research  Implications 

Design  recovery  of  the  OS  X  kernel  data  structures  related  to  process  file  handles 
in  Section  3.2  and  summarized  in  Appendix  B  is  a  primary  implication  of  the  research. 
Development  of  the  new  volafox  module  for  parsing  handle  information  exists  in  part  to 
demonstrate  this  part  of  the  methodology  in  a  practical  form.  While  core  UNIX 
technologies  lead  to  many  similarities  with  other  systems,  OS  X’s  unique  design 
architecture  makes  it  distinct  from  other  platforms.  The  research  is  novel  because  kernel 
structures  parsed  by  the  tool  differ  from  those  considered  in  the  literature  for  Linux  and 
Windows. 

The  research  module  also  demonstrates  a  process  developed  for  dynamically 
handling  data  structure  layout  in  memory  across  multiple  architecture  and  operating 
system  versions.  The  process  is  broken  down  in  three  parts.  Section  3.4.2  first  describes 
how  C  struct  templates  are  built  to  an  interface  specification  for  each  OS  and  architecture 
configuration.  Next,  a  solution  is  given  for  selecting  the  correct  template  at  runtime  using 
an  abstract  object  initializer.  Finally,  Section  3.4.3  presents  an  external  C  program  for 
generating  template  syntax  using  the  kernel  header  files  defining  key  structures.  The 
process  itself  adds  value  because  it  simplifies  program  logic  and  readability  of  the 
resulting  source  code.  Though  unverified,  the  process  is  extensible  by  design  and 
therefore  may  also  support  future  versions  of  OS  X  and  additional  kernel  structures 
outside  the  immediate  research  scope. 

Finally,  the  new  volafox  module  for  listing  open  files  is  validated  in  Chapter  4 
and  found  to  reasonably  approximate  output  from  the  UNIX  Isof  command.  After 
addressing  outstanding  constraints  and  deficiencies,  work  based  on  this  tool  could  one 
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day  replace  at  least  one  required  executable  from  an  incident  response  toolkit.  This  result 
directly  addresses  the  problem  statement  and  therefore  implies  a  successful  research 
outcome. 
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II.  Literature  Review 


Digital  evidence  is  integral  to  modem  forensic  investigation  because  of  its 
pervasiveness  in  the  consumer,  enterprise,  and  government  domains.  Practitioners  require 
tools  to  simplify  the  collection  and  analysis  of  such  evidence  across  the  breadth  of 
endpoint  devices  encountered  in  the  field.  An  investigator  may  employ  tools  from  a 
variety  of  open-source,  commercial,  and  underground  sources  in  pursuit  of  needed 
capabilities.  The  work  presented  in  this  thesis  evolves  an  existing  open-source  project  for 
analyzing  the  memory  of  Apple’s  OS  X  desktop  operating  system. 

This  chapter  introduces  digital  forensics  and  the  related  process  of  incident 
response,  with  specific  focus  on  memory  analysis.  Strategies  for  capturing  memory  on 
OS  X  are  discussed  as  a  component  of  incident  response,  and  necessary  precursor  to 
analysis.  A  review  of  existing  work  for  analyzing  raw  memory  dmmped  on  Linux  serves 
as  a  baseline  for  higher-abstraction  analytic  capabilities.  Finally,  the  volafox  tool  being 
extended  for  this  research  is  presented,  along  with  its  methodology  for  acquiring  kernel 
symbols  and  parsing  key  data  stmctures. 


2.1  Digital  Forensics 

The  National  Institute  of  Justice  (NIJ)  describes  digital  evidence  as  “[ijnformation 
stored  in  binary  form  that  may  be  introduced  and  relied  on  in  court”  (2008,  p.  52).  In 
order  to  meet  the  latter  half  of  this  definition,  evidence  must  be  handled  in  a  manner 
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consistent  with  accepted  forensic  practice.  Generally  accepted  standards  include  at 
minimum  (NIJ,  2008): 

•  A  process  for  ensuring  evidence  remains  unchanged. 

•  Assuring  technical  expertise  of  personnel  responsible  for  analysis. 

•  Detailed  documentation  of  all  actions  affecting  the  evidence. 

A  similar  definition  by  the  National  Institute  of  Standards  and  Technology  (NIST) 
describes  computer  forensics  as  the  “practice  of  gathering,  retaining,  and  analyzing 
computer-related  data  for  investigative  purposes  in  a  manner  that  maintains  the  integrity 
of  the  data”  (2008,  p.  D-1).  Digital  forensics  is  therefore  a  process  characterized  by  the 
preparation  for,  and  execution  of,  the  following  activities  (NIST,  2006): 

1 .  Data  collection  -  identifying  and  preserving  useful  data  from  all  possible  sources 
of  digital  evidence  according  to  a  standardized  subprocess. 

2.  Examination  and  analysis  -  a  methodical  approach  to  correlating  evidence  from 
various  sources  to  determine  the  characteristics  and  impact  of  an  event. 

3.  Reporting  -  a  procedural  log  and  analysis  summary  used  to  demonstrate  the 
integrity  of  the  process  overall  and  present  its  findings. 

Given  the  wide  array  of  platforms  and  environments  capable  of  supporting  digital 

evidence,  these  definitions  describe  what  the  digital  forensic  process  requires  rather  than 

how  to  accomplish  it. 

The  implementation  described  in  Chapter  3  is  specific  to  the  evidence  analysis 
component  of  the  three-part  process  above.  However,  in  order  to  understand  the  input  for 
analysis,  the  collection  of  digital  evidence  is  discussed  here. 


8 


2,2  Incident  Response 

Motivation  for  applying  the  digital  forensic  process  is  known  as  an  incident, 
“violation  or  imminent  threat  of  violation  of  computer  security  policies,  acceptable  use 
policies,  or  standard  security  practices”  (NIST,  2008,  p.  D2).  Organizations  with  a 
mission  involving  digital  forensics  need  an  established  policy  for  handling  such  events 
that  describes  recommended  practices  for  mitigating  the  effects.  Performing  the  actions 
prescribed  in  such  a  policy  is  defined  as  incident  response,  an  organizational  standard 
describing  how  the  process  of  digital  forensics  is  to  be  applied  within  a  specific  context. 
An  incident  response  almost  always  incorporates  components  of  data  collection  and 
reporting  as  specified  by  the  digital  forensics  process.  Depending  on  mission  needs  of  the 
affected  systems,  analysis  may  take  place  on  site,  be  deferred,  or  a  combination  of  the 
two.  Deferred  analysis  may  be  necessary  when  it  requires  technical  skills  beyond  that  of 
incident  responder,  tools  unavailable  at  the  scene,  or  is  expected  to  take  more  time  than 
can  be  reasonably  allocated. 

The  tool  implemented  in  Chapter  3  could  operate  as  a  component  of  incident 
response  but  is  more  likely  to  be  employed  during  deferred  analysis.  Data  used  as  input  to 
the  tool  is  volatile  and  therefore  its  capture  must  be  conducted  as  part  of  an  incident 
response  policy  in  order  to  make  analysis  possible. 

2.2.1  Volatile  Data. 

Volatile  data  describes  digital  evidence  of  a  dynamic  or  transient  nature  that  is 
sensitive  to  time,  system  state,  or  power.  It  is  contrasted  with  nonvolatile  data  such  as  that 
stored  on  a  magnetic  hard  drive,  smart  card,  or  flash  memory  (NIJ,  2008).  While  sources 
of  nonvolatile  data  may  be  collected  directly  as  hardware  or  imaged  during  incident 
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response,  volatile  data  is  fragile  and  therefore  has  distinet  eolleetion  and  analysis  needs 
(NIST,  2006).  This  seetion  motivates  the  eolleetion  of  volatile  data  during  ineident 
response  as  a  eompliment  to  traditional  disk  analysis,  and  provides  an  overview  of  the 
proeess.  Note  that  system  eharaeteristies  and  the  eolleetion  proeess  deseribed  foeus  on 
Linux  systems  due  to  similarity  with  OS  X. 

Several  arguments  for  seizing  and  analyzing  volatile  data  exist.  First,  no  usage 
snapshot  is  eomplete  without  a  reeord  of  what  the  maehine  was  doing  before  shutdown. 
This  aetion  is  usually  a  prerequisite  to  imaging  a  system  for  deferred  disk  analysis  (NIST, 
2006).  Valuable  evidenee  sueh  as  running  proeesses,  network  eonneetions,  and  eurrently 
open  files  may  all  be  irretrievably  lost  as  soon  as  the  target  is  powered  off  (NIST,  2008). 
Critieal  systems  may  also  be  unavailable  for  imaging  beeause  the  downtime  would 
adversely  affeet  user  experienee  or  serviees,  making  traditional  disk  analysis  infeasible. 
The  so-ealled  Trojan  Defense  is  also  a  eoneem.  One  elassie  example  is  Aaron  Caffrey’s 
aequittal  following  a  defense  whieh  eould  have  been  disproven  using  evidenee  in  volatile 
data  (Leyden,  2003).  Modern  malware  is  speeifieally  engineered  to  avoid  the  disk  as  a 
means  of  preventing  deteetion.  This  means  volatile  data  may  be  the  only  souree  of 
evidenee  available  to  prove  its  presenee  or  absenee.  Dolan-Gavitt  (2008a)  demonstrates 
how  a  eaehed  version  of  the  Windows  registry  ean  be  exploited  without  leaving  any 
evidenee  on  the  disk. 

The  slow  but  progressive  adoption  of  full-disk  eneryption  offers  what  may  be  the 
single  best  argument  for  integrating  volatile  data  eolleetion  into  any  reasonable  ineident 
response  (Casey,  Fellows,  Geiger,  &  Stellatos,  2011).  Data  on  disk  may  be  essentially 
worthless  to  the  investigator  onee  the  target  is  powered  off  if  its  eontents  beeome  fully 
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encrypted.  Full  disk  encryption  became  a  standard  feature  on  OS  X  when  FileVault  2  was 
included  with  the  release  of  10.7  Lion.  Tools  for  breaking  FileVault  2  encryption  via 
memory  exploit  are  now  available  both  open  source  and  commercially  (Kessler,  2012; 
Maartmann-Moe,  2012).  However,  none  of  the  known  attacks  work  after  the  target  is 
turned  off. 

2.2.2  Volatile  Collection  Process. 

Recovering  volatile  data  from  a  Linux  target  typically  involves  a  toolkit 
consisting  of  trusted  executables  needed  to  dump  specific  operating  system  information, 
exfiltrate  output,  and  maintain  integrity  of  evidence  (Mandia,  Prosise,  &  Pepe,  2003).  On 
UNIX  systems  and  their  derivatives,  the  toolkit  can  be  built  using  commands  available  on 
the  platform,  compiled  as  static  binaries  verified  using  the  Idd  tool  on  Linux  (Burdach, 
2004),  or  otool  on  the  Mac  (Webb,  2010).  The  volatile  data  of  interest  and  some  of  the 
Linux  commands  associated  with  its  collection  are  summarized  below  (Burdach,  2004; 
Carvey,  2009;  Mandia  et  ah,  2003): 

•  date  -  system  date  and  time 

•  w  -  login  sessions 

•  Is-  directory  listing  including  MAC  times 

•  netstat  -  network  connections  and  open  ports  with  associated  applications 

•  ps  -  process  list 

•  arp,  route  -  arp  and  routing  cache  tables 

•  cat  /proc /mo dule s  -  loaded  kernel  modules 

•  1  s  o  f  -  process-to-file  mappings 

•  cat  /proc/version  -  OS  version 

•  cat  /proc/ sys/ kernel /name  -  host  name 

•  cat  /proc/ sys/ kernel /domainame  -  domain  name 

•  cat  /proc/cpuinfo  -  hardware  info 

•  cat  /proc /  swap s  -  swap  partitions 

•  cat  /proc/part  it  ions  -  local  file  systems 

•  cat  /proc/self /mounts  -  mounted  file  systems 
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•  cat  /proc/uptime  -  uptime 

•  Physical  memory  image  (kernel-specific) 

•  Clipboard  contents  (distribution-specific) 

•  Command-line  history  (shell-specific) 

The  toolkit  is  typically  delivered  to  the  target  via  read-only  media  to  protect  its  integrity, 
and  its  output  usually  stored  to  external  media  or  piped  over  a  network  connection.  After 
constructing  such  a  toolkit,  commands  for  collecting,  naming,  and  storing  the  evidence 
collected  are  scripted  for  the  native  command-line  interface.  The  command  order  should 
give  consideration  to  the  perishability  of  the  data  (NIST,  2006): 

1 .  Network  connections 

2.  Login  sessions 

3.  Contents  of  memory 

4.  Running  processes 

5.  Open  files 

6.  Network  configuration 

7.  Operating  system  time 

Webb  offers  details  on  toolkit  compilation  and  scripting  for  incident  response  on  OS  X 
which  roughly  approximates  the  aforementioned  process  (2010). 

A  possible  alternative  to  this  incident  response  methodology  by  Choi,  Savoldi, 
Gubian,  and  Lee  (2008)  integrates  both  collection  and  analysis.  The  Linux  Evidence 
Collection  Tool  (LECT)  is  a  framework  for  live  evidence  collection  aimed  at  server 
investigations.  It  consists  of  a  console-based  collection  tool  and  graphical  analysis 
environment.  The  tool  emphasizes  collection  of  log  files  and  other  disk-home  data  for 
offline  analysis  and  correlation  with  volatile  data.  Because  of  this  hybrid  approach,  EECT 
is  not  well  aligned  with  the  research  goals  of  this  thesis. 

The  preceding  exploration  of  volatile  collection  strategies  for  Einux  serves  to 
characterize  the  kinds  of  information  that  are  most  critical  to  the  investigator.  In  the 
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following  section,  an  alternative  methodology  is  proposed  to  replace  many  of  the 
commands  mentioned  with  a  tool  for  parsing  this  information  from  an  image  of  physical 
memory.  Use  of  a  volatile  collection  toolkit  as  described  in  this  section  establishes  a 
baseline  against  which  memory  forensics  can  be  measured  in  terms  of  both  analytic 
power  and  system  impact. 

2,3  Memory  Forensics 

This  section  describes  background  needed  to  understand  the  sub-field  of  digital 
forensics  concerned  with  analyzing  the  contents  of  raw  memory.  Random-access  memory 
(RAM),  physical  memory,  or  main  memory  are  all  terms  used  interchangeably  to 
describe  the  first  backing  store  for  the  operating  system’s  virtual  memory  manager 
(Gorman,  2004).  Physical  memory  is  of  interest  to  the  forensic  examiner  because  it  stores 
current  and  recent  data  being  acted  on  by  the  CPU  and  various  memory-mapped  I/O. 
Suiche  (2010)  asserts  that  on  UNIX  systems  the  term  physical  memory  is  synonymous 
with  /dev /mem,  the  character  device  used  to  abstract  the  hardware  implementation. 

A  variety  of  hardware  and  software  solutions  exist  to  copy  the  contents  of 
physical  memory  to  file  for  offline  analysis.  Output  of  such  a  tool  is  commonly  referred 
to  as  an  image  or  memory  dump.  The  sophistication  of  memory  analysis  varies,  but  by 
one  definition  represents  an  “attempt  to  use  memory  management  structures  in  computers 
as  maps  to  extract  files  and  executables  resident  in  a  computer’s  physical  memory” 
(Urrea,  2006,  p.  2).  The  more  specific  definition  required  by  this  research  classifies 
structured  memory  analysis  as  the  examination  of  kernel  structures  present  in  an  image  to 
partially  characterize  the  state  of  a  computer  at  time  of  capture.  The  two-part  process  of 
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analyzing  physical  memory  generally  involves  the  eapture  of  RAM  during  ineident 
response  in  a  manner  eonsistent  with  forensie  prineiples,  and  subsequent  examination  of 
its  eontents  using  tools  eapable  of  parsing  kernel  struetures  or  other  useful  patterns  from 
the  resulting  file. 

In  its  simplest  form,  the  value  of  memory  introspeetion  will  be  familiar  to  any 
programmer  who  has  used  a  debugger  to  analyze  a  eore  dump.  Exploit  developers  use 
many  of  the  same  tools  for  analyzing  the  state  of  RAM  during  exeeution  to  eraft  payloads 
for  eorrupting  memory  in  order  to  aehieve  a  desired  effeet  (Miller  &  Zovi,  2009). 
Analysts  on  both  sides  of  the  ethieal  divide  observe  memory  in  aetion  to  reverse  engineer 
systems,  applieations,  or  malware.  From  a  forensie  standpoint,  the  state  of  a  system  ean 
be  most  eomprehensively  reeorded  by  eapturing  the  raw  eontents  of  RAM.  However, 
modem  eomputers  guarantee  this  information  alone  is  ineomplete  and  fragmented  due  to 
virtual  memory  and  other  arehiteetural  meehanisms.  Further  eomplicating  its  analysis  are 
operating  system  proteetion  sehemes  sueh  as  Address  Spaee  Fayout  Randomization 
(ASFR),  whieh  seek  to  obfuseate  the  loeation  and  stmeture  of  memory  as  a  means  of 
safeguarding  information. 

2.3.1  Advantages  of  Memory  Analysis. 

Despite  the  ehallenges,  there  are  several  eompelling  reasons  to  prefer  stmetured 
memory  analysis  over  the  teehniques  for  investigating  volatile  data  deseribed  in  Seetion 
2.2.1.  First,  beeause  memory  eontains  both  in-use  and  reeently-used  data,  it  is  possible  to 
reeonstmet  a  limited  timeline  of  system  usage.  Reeently  used  memory  segments  may 
provide  information  not  represented  in  the  log  files  and  other  ineident  response  toolkit 
output  beeause,  like  free  disk  spaee,  these  segments  are  marked  for  reeyeling  by  the 
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operating  system.  Solomon,  Huebner,  Bern,  and  Szezynska  assert  that  “[djespite  the  fast 
deeay  of  user  pages  in  free  memory,  it  is  still  a  worthwhile  souree  of  forensic  data” 
(2007,  p.  71).  The  most  recent  work  on  Linux  even  suggests  that  it  may  be  possible  to  go 
about  such  reconstruction  in  a  coherent  and  organized  fashion  (Case,  Marziale,  Neckar, 
&  Richard,  2010). 

A  second  advantage  of  structured  memory  analysis  is  its  resilience  to  system 
tampering  when  compared  with  other  strategies  for  reconstruction  using  disk  analysis  or 
incident  response  toolkit  output.  Syscall  hooking,  log  manipulation,  and  other  anti- 
forensic  measures  are  common  features  of  modem  malware  (Ligh,  Adair,  Hartstein,  & 
Richard,  2011;  SANS  Institute,  2008).  These  exploitation  tactics  can  lead  to  missed 
evidence  and  incorrect  conclusions  if  the  results  of  other  analysis  are  not  compared 
against  evidence  in  memory  (Hay  &  Nance,  2009).  Even  when  employing  static 
executables,  memory  analysis  may  be  the  only  way  to  reveal  mnning  malware  when 
faced  with  a  sophisticated  kernel  rootkit.  Dolan-Gavitt  (2008a)  also  demonstrates  how 
physical  memory  may  contain  the  only  evidence  of  registry  tampering  on  Windows. 

The  third  benefit  is  that  physical  memory  may  contain  evidence  that  is  never 
saved  to  disk  and  would  otherwise  be  lost.  Consider  that  one  reason  for  performing  hard 
power-off  of  a  system  prior  to  imaging  is  to  preserve  the  temporary  files  that  might  be 
overwritten  in  a  graceful  shutdown  operation  (NIST,  2006).  This  action  also  results  in  the 
unfortunate  loss  of  any  files  that  have  not  been  saved  because  they  exist  only  in  memory 
at  the  time  of  shutdown.  If  memory  is  imaged  during  the  incident  response,  these  files  are 
preserved  and  “sections  of  memory  can  have  more  traditional  forensic  procedures  applied 
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to  them  such  as  file  carving  and  hashing”  (Case,  Cristina,  Marziale,  G.  G.  Richard,  & 
Roussev,  2008,  p.  S70). 

Finally,  volatile  data  collection  using  a  scripted  response  toolkit  has  an  inherent 
disadvantage:  changes  to  the  system  state  which  occur  as  a  result  of  collection.  Dumping 
information  in  a  forensically  sound  manner  means  “[s]ome  of  the  response  tools  may 
even  substantially  alter  the  digital  environment  of  the  original  system”  (Law,  Chow, 
Kwan,  &  Lai,  2007,  p.  137).  A  trusted  tool  must  overwrite  existing  memory  on  the  target 
system  when  both  the  executable  and  all  its  static  libraries  are  copied  from  disk  in  order 
to  preserve  the  forensic  integrity  of  the  output.  Next,  a  series  of  I/O  operations  are  needed 
to  support  the  exfiltration  of  the  output.  The  process  is  then  repeated  for  each  distinct 
piece  of  volatile  data  sought.  This  leads  to  a  situation  where  “[t]he  credibility  of  the 
acquired  data  relies  solely  on  the  reliability  of  the  tool  and  the  expertise  of  the  user”  (Law 
et  ah,  2009,  p.  1).  By  contrast,  capturing  physical  memory  for  deferred  analysis  has  the 
potential  to  be  much  less  invasive.  Some  techniques,  such  as  FireWire  acquisition,  do  not 
require  any  execution  on  the  target  system.  Similarly,  suspending  a  virtual  machine 
allows  memory  capture  on  the  guest  with  minimal  impact. 

The  lack  of  investigator-friendly  methods  for  analyzing  memory  images  provides 
the  facing  argument  to  the  use  of  structured  memory  analysis  outlined  in  the  preceding 
paragraphs.  When  deciding  between  an  imperfect  incident  response  toolkit  and  an 
indecipherable  collection  of  bits,  it  is  clear  that  a  potentially  corrupt  dataset  is  preferable 
to  no  information  at  all.  A  dump  of  raw  memory  is  only  as  useful  as  the  tools  available  to 
abstract  information  for  human  analysis.  Therefore  the  acquisition  and  analysis 
capabilities  for  this  method  are  equally  important. 
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2.3.2  Memory  Forensics  Process. 

Analysis  of  raw  memory  is  procedurally  similar  to  many  types  of  digital  evidenee, 
generally  following  the  steps  of  eapture,  analysis,  and  reporting.  Carvey  (2009)  provides 
a  deseription  of  the  memory  forensics  process,  with  a  focus  on  Windows  since  it  is  the 
only  platform  where  this  type  of  analysis  has  matured. 

The  first  step  is  to  choose  a  method  of  capture  based  on  the  hardware,  operating 
system,  state  of  the  target,  and  context  of  the  investigation.  Next,  a  delivery  method  is 
selected.  Most  common  today  is  a  USB  device  that  acts  as  both  capture  toolkit  and 
storage  for  the  resulting  memory  image.  The  toolkit  hash  is  documented  prior  to  use,  and 
appropriate  physical  and  policy  measures  taken  to  prevent  altering  the  contents  of  the 
device  before  incident  response.  When  the  tool  is  executed  on  a  target,  system  time  and 
hash  value  of  the  output  are  documented  in  the  incident  response  log.  Carvey  (2009) 
argues  the  hash  should  be  recorded  once  memory  dump  is  complete  due  to  changes  that 
occur  during  the  capture  process.  After  memory  is  captured,  measures  must  again  be 
taken  to  avoid  changes  to  the  storage  media.  Analysis  occurs  only  on  copies  of  the 
original  image  file,  the  integrity  of  which  can  be  verified  using  the  recorded  hash.  This  is 
done  using  a  write-blocker  on  a  forensic  workstation  capable  of  copying  the  storage 
media  without  changing  it.  Analysis  then  proceeds  on  the  copy  according  to  the  needs  of 
the  investigation  and  the  tools  available.  The  process  for  parsing  any  results  is 
documented  in  detail  such  that  it  can  be  reproduced,  and  the  conclusions  of  the  examiner 
are  summarized  in  a  written  report.  Since  the  reporting  aspect  is  largely  determined  by 
organization  policy  or  legal  requirements  it  is  not  discussed  further,  but  the  details  of 
capture  and  analysis  for  OS  X  and  similar  platforms  are  now  presented. 
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2,4  Mac  Memory  Acquisition 

This  section  focuses  on  physical  memory  capture  for  the  platform  under  research 
consideration:  OS  X  running  on  Intel  architecture.  While  this  thesis  addresses  primarily 
the  analysis  component  of  the  memory  forensics  process,  acquisition  of  RAM  is  a 
prerequisite  to  making  such  research  worthwhile  and  is  therefore  discussed  first. 

2.4.1  FireWire,  Cold-boot,  and  VM Extraction. 

The  IEEE  1394  or  EireWire  interface  is  susceptible  to  direct  memory  access 
(DMA)  on  OS  X  as  well  as  Windows.  Its  vulnerability,  the  underlying  PCIe  bus,  is 
shared  by  a  variety  of  I/O  on  the  Mac  including  ExpressCard,  SD  slot,  and  the  new  Intel 
Thunderbolt  port  (Graham,  2011).  Using  this  interface  to  reliably  capture  RAM  on  the 
Mac  was  first  demonstrated  by  the  pyfw  attack  (Becher,  Domseif,  &  Klein,  2005). 
While  useful,  the  project  is  not  explicitly  designed  as  a  forensic  tool  (Hermann,  2008). 
Numerous  forensic  implementations  have  emerged  since,  including  Goldfish  (Gladyshev 
&  Almansoori,  2010,  2011),  and  libforensicl394  (Witherden,  2010). 

There  are  several  shortcomings  to  DMA  capture.  Eirst,  the  vulnerability  is  limited 
to  the  first  4GB  of  system  memory  (Gladyshev  &  Almansoori,  2010).  Kubasiak  and 
Morrissey  further  characterize  the  method  as  “somewhat  invasive  and  involves  tricking 
the  system  into  thinking  an  iPod  is  being  connected”  (2009,  p.  528).  Einally,  the  attack  is 
easily  mitigated  using  the  lock  screen  if  user  switching  is  disabled  (Garrison,  2011). 

The  alternative  Kubasiak  and  Morrissey  suggest  to  EireWire  exploitation  is 
msramdump  (2009,  p.  528;  McGrew,  2008).  This  technique  calls  for  cold  boot 
extraction,  where  the  target  system  is  forcibly  shutdown  and  then  quickly  booted  from 
external  media  before  the  contents  in  memory  are  fully  wiped  by  momentary  loss  of 
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power.  This  tool  builds  on  earlier  researeh  where  the  hardware  DIMMS  were  physieally 
eooled  and  removed  from  the  target  so  the  eontents  eould  be  read  externally.  The  risk  of 
evidence  loss  appears  to  be  high  with  this  strategy  and  the  authors  suggest  it  only  as  a 
method  of  last  resort  for  extracting  the  decryption  key  of  a  Mac  using  FileVault. 

Another  option  is  to  copy  the  memory  backup  file  maintained  by  the  host  system 
of  an  OS  X  virtual  machine  (VM)  during  suspension.  Ligh,  Adair,  Hartstein  and  Richard 
list  the  location  of  such  files  for  various  virtualization  products  and  describe  how  they 
can  be  used  with  Volatility  for  Windows  analysis  (2011).  This  represents  perhaps  the 
least  invasive  method  available,  however  there  are  two  caveats.  First,  until  the  release  of 
OS  X  10.7  Apple’s  software  license  agreement  only  permitted  virtualization  of  its  server 
operating  system.  Second,  due  to  tight  hardware-software  integration  on  the  Mac  it  would 
be  rare  to  encounter  such  an  installation  in  the  field,  thereby  limiting  its  usefulness  to  the 
forensic  examiner.  Possible  exceptions  include  enterprise  installations  of  OS  X  Server  or 
VMs  used  for  research,  software  development,  or  reverse  code  engineering. 

2.4.2  Kernel  Module  Capture. 

Classic  methods  for  extracting  memory  from  UNIX  systems  involved  reading 
directly  from  the  /dev/mem  or  /dev/kmem  character  device  using  dd.  This  ability  has 
been  disabled  in  the  Linux  kernel  for  some  time  and  when  OS  X  transitioned  to  Intel 
architecture  it  became  similarly  depreciated  on  the  Mac.  Singh  (2006a)  describes  the 
problem  and  makes  several  suggestions  for  implementing  a  custom  version  of 
/dev/kmem  to  read  from  kernel  memory  directly.  This  approach  was  demonstrated  by 
Suiche  (2010)  with  an  emulation  of  /dev/mem  used  to  dump  RAM  on  a  Mac.  The 
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presentation  also  describes  how  critical  symbols  retrieved  from  the  mach_kernel 
executable  can  be  used  to  build  a  kernel  memory  manager  capable  of  virtual  to  physical 
address  translation.  Such  translation  is  required  to  fully  browse  kernel  address  space  and 
copy  its  contents.  This  capability  did  not  become  publically  available  until  the  release  of 
Mac  Memory  Reader  (Architecture  Technology  Corporation  [ATC],  2011),  a  free 
component  of  the  commercial  Mac  Marshal  product.  Technical  limitations  and  design 
decisions  lead  to  several  details  worth  nothing  about  the  tool’s  output  (ATC,  2011;  Inoue, 
Adelstein,  &  Joyce,  2011;  Leat,  2011): 

•  Output  file  format  is  a  Mach-0,  equivalent  to  Linux  ELF  (Apple  Inc.,  2009). 

•  The  -H  option  prints  MD5,  SHA-1,  SHA-256,  or  SHA-512  hash  to  stderr. 

•  Using  for  the  output  filename  prints  to  s  tdout  for  command  piping. 

•  Physical  memory  map  used  is  the  same  format  as  the  showbootermemory 
macro  in  the  Apple  Kernel  Debug  Kit. 

•  Only  addressable  pages  can  be  copied  from  physical  memory,  excluding  a  small 
number  of  pages  missing  from  the  memory  map. 

•  Memory  segmentation  is  maintained  along  with  offsets  in  the  file  using  a  header 
listing,  the  results  of  which  can  be  interpreted  with  Apple’s  otool. 

•  Memory-mapped  I/O  device  segments  and  memory  ports  are  not  captured. 

•  Memory  allocated  to  a  virtual  machine  hypervisor  is  not  captured. 

There  are  several  disadvantages  to  this  form  of  acquisition.  First,  Mac  Memory 
Reader  requires  administrator  privileges  to  load  the  needed  kernel  module.  While  this 
may  limit  its  use  during  some  investigations,  in  many  cases  a  cooperative  administrator 
may  be  available  to  provide  the  password.  Second,  output  from  such  a  tool  could  be 
corrupted  by  the  presence  of  memory  forensic  countermeasures  (Haruyama  &  Suzuki, 
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2012)  or  advent  of  a  rootkit  explicitly  designed  to  subvert  collection.  “Fortunately,  unless 

the  subversion  mechanism  is  very  deeply  embedded  in  the  OS,  a  substantial  amount  of 

overhead  may  be  incurred  to  prevent  acquisition,  potentially  revealing  the  presence  of  a 

malicious  agent”  (Case  et  ah,  2008,  p.  2).  Finally,  because  a  kernel  module  must  be 

loaded  into  the  memory  in  order  to  perform  the  capture,  its  use  alters  the  target  system. 

The  problem  is  addressed  by  the  Mac  Memory  Reader  README  text  (ATC,  2011): 

Pieces  of  the  MacMemoryReader  executable  code  and  data  will  certainly 
appear  within  the  RAM  snapshot,  simply  because  MacMemoryReader  is 
running  in  the  same  memory  space  being  acquired.  This  is  a  known 
"footprint"  and  aspect  of  live  analysis. 

While  this  represents  a  violation  of  the  first  forensic  principle  outlined  in  section  2.1,  it  is 
likely  to  be  no  worse  than  the  other  practical  methods  discussed  (VM  analysis 
notwithstanding).  This  method  of  capture  also  has  the  advantage  of  being  self- 
documenting,  in  that  its  usage  is  represented  within  the  resulting  output.  Despite  the 
challenges,  availability  of  this  robust  acquisition  capability  for  the  Mac  encourages 
additional  research  and  emphasis  on  analytic  capabilities  for  the  platform. 

2,5  Structured  Memory  Analysis 

Most  literature  and  web  references  to  memory  analysis  on  OS  X  discuss  context- 
free  techniques  such  as  string  searches,  manual  hex  examination,  file  carving  and  the  like. 
Valenzuela  (2011)  writes  about  these  rudimentary  methods  in  a  blog  post  responding  to 
the  release  of  Mac  Memory  Reader.  Malard  (2011)  expands  these  approaches  to  include 
session  information  and  password  extraction  in  a  paper  discussing  hacking  tactics  for  OS 
X.  One  early  effort  to  achieve  systematic  analysis  of  raw  memory  on  the  Mac  is  a  tool  for 
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automatically  extracting  login  credentials  using  the  FireWire  exploit  eited  previously 
(Makinen,  2008).  The  attack  iterates  over  all  pages  in  memory  searching  for  a  string  flag 
known  to  occur  at  a  particular  offset  and  then  performs  a  keyword  seareh  for  ‘username’ 
and  ‘password’  within  that  page  to  reveal  the  target  information.  This  tool  is  valuable  for 
deerypting  disks  with  FileVault  enabled  but  is  only  effective  against  OS  X  10.4  Tiger. 
Unfortunately,  all  eontext-free  methods  for  memory  analysis  are  inherently  limited, 
impreeise,  and  ineffieient. 

2.5.1  Linux  Memory  Analysis. 

This  section  offers  a  review  of  existing  work  coneeming  higher-abstraction 
memory  analysis,  presented  as  a  timeline.  Linux  is  ehosen  as  a  reasonable  analog  upon 
which  to  model  researeh  for  OS  X  because  it  is  the  most  similar  platform  to  have 
received  attention  in  the  literature  with  regard  to  forensic  memory  analysis.  However, 
note  that  Linux  diverges  signifieantly  in  terms  of  the  kernel  structures  used  to  reeonstruet 
information  (Singh,  2006b). 

An  early  paper  on  memory  analysis  for  Linux  proposes  tools  to  aid  embedded 
developers  with  identifying  misused  or  wasted  system  memory  (Movall,  Nelson,  & 
Wetzstein,  2005).  While  not  well  suited  for  forensie  applieation,  this  work  demonstrates 
how  memory  forensies  follows  as  a  natural  extension  of  dynamie  debugging.  Burdaeh 
demonstrates  this  coneept  in  a  2004  blog  post  on  live  forensie  analysis  for  Linux  systems. 
The  blog  notes  aequisition  of  /proc/kcore  should  be  favored  over  /dev/mem 
because  its  ELF  core  format  allows  for  introspection  using  gbd.  By  comparing  the 
addresses  in  Symbol. map  with  those  from  /proc/kcore,  the  author  demonstrates 
how  memory  analysis  can  be  used  to  perform  rootkit  deteetion.  There  is  also  a 
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description  of  how  /proc/kcore  can  yield  keyword  searches  with  the  UNIX  strings 
command  and  regular  expressions. 

Moving  beyond  keyword  searches  and  file  carving  techniques  requires  an 
understanding  of  operating  system  internals  to  determine  how  the  kernel  organizes 
information  in  what  would  otherwise  be  an  incoherent  block  of  data.  Urrea  (2006)  began 
this  work  by  enumerating  many  of  the  Linux  structures  relevant  to  forensic  examination 
and  shows  how  they  might  be  extracted  using  a  set  of  ridged  Perl  scripts.  Burdach  (2006) 
continued  to  enhance  the  analytic  potential  on  the  platform  when  he  released  a  proof-of- 
concept  toolkit  called  IDETECT  to  simplify  introspection  on  memory,  again  using  gdb. 
The  same  year  EATKit  framework  (Petroni,  Walters,  Eraser,  &  Arbaugh,  2006)  emerged 
as  a  major  step  forward  by  offering  a  modular  approach  to  abstracting  and  visualizing 
forensic  evidence  from  raw  memory.  Tool  design  is  general  and  extensible  enough  that 
even  in  early  releases  EATKit  featured  modules  for  both  Windows  and  Einux. 

Case,  Cristina,  Marziale,  Richard,  and  Roussev  developed  RAMPARSER  to 
address  “the  lack  of  available  memory  parsing  tools  for  Einux”  (2008,  p.  S67). 
RAMPARSER  can  list  running  processes  and  perform  introspection  on  specific  ones  to 
detail  open  files  and  socket  information.  Case,  Marziale  and  Richard  (2010)  later  extend 
RAMPARSER  to  make  it  “substantially  less  brittle  with  respect  to  kernel  versions”.  This 
paper  frames  one  of  the  major  challenges  to  forensic  memory  analysis:  most  tools  are 
specific  to  a  particular  platform  version  and  must  be  reworked  when  even  minor  updates 
to  an  operating  system  occur.  The  constraint  is  especially  dire  for  Einux  distributions, 
where  there  is  a  great  deal  of  kernel  fragmentation.  This  same  challenge  is  also  the 
motivation  for  Eoriana  (Petroni,  Walters,  Eraser,  &  Arbaugh,  2006),  a  research  tool 
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designed  to  explore  solutions  for  memory  analysis  when  the  exact  target  OS  version  is 
not  known.  The  tool  has  support  for  multiple  architectures  and  operating  systems, 
including  BSD  (from  which  Apple’s  UNIX  foundation  derives).  Vidas  (2011)  suggests  an 
open  corpus  for  memory  analysis  to  build  support  across  a  breadth  of  kernel  versions. 

While  most  of  the  work  discussed  exists  primarily  in  the  research  domain,  tools 
for  Linux  memory  analysis  are  also  represented  commercially  (Pikewerks  Corporation, 
2011).  However,  the  open  source  forensics  community  has  been  slow  to  support  Linux 
with  tools  built  for  users  when  compared  to  the  capabilities  available  for  Windows.  In 
2008  serious  work  began  on  this  deficiency  when  the  Digital  Forensics  Research 
Workshop  (DFRWS)  sought  to  develop  tools  specifically  for  Linux  memory  analysis. 
This  emphasis  resulted  in  several  Linux  extensions  for  the  open  source  Volatility 
framework  (Cohen  &  Collett,  2008).  Case  (2011a,  b,  c)  writes  extensively  about 
subsequent  work  leading  to  the  Linux  branch  available  in  beta  from  the  Volatility  project 
website.  Integrated  Linux  support  is  anticipated  for  the  3.0  release  of  the  project  (M. 
Cohen,  Volatility  developer  mailing  list,  March  26,  2012).  In  addition  to  the  Linux 
commands  shown  in  Table  1,  Volatility  has  additional  modules  for  analyzing  network 
configuration,  kmem  cache,  dmesg  buffer,  and  auxiliary  process  details. 

2.5,2  Volaf ox  Project. 

The  first  effort  to  provide  higher-abstraction  analytic  capabilities  for  raw  memory 
dumped  on  the  Mac  began  with  the  open  source  release  of  volafox,  a  Google  Code 
project  described  as  a  “Memory  Analyzer  for  Mac  OS  X”  (Lee,  2011).  This  text-based 
tool  is  implemented  in  Python  2.5  and  borrows  heavily  from  the  Volatility  source  code. 
Volafox  is  operable  on  flat  memory  images  captured  from  OS  X  10.6-7  with  32  or  64-bit 


24 


Table  1.  volafox  modules  and  their  Volatility  equivalents. 


volafox 

osx 

Terminal 

Volatility 
(  Linux  branch  ) 

Description 

OS  version 

sw  vers 

OS  X  build  version 

machine  info 

sysctl 

linux  cpuinfo 

kernel  version,  CPU,  and 
memory  specifications 

mount  info 

mount 

linux  mount 

mounted  filesystems 

kext  info 

kextstat 

linux  Ismod 

kernel  extension  (KEXT)  list 

-m 

KEXT dump 

proc  info 

ps 

linux  task  list  ps 

process  list 

-X 

vminap 

linux  proc  maps 

process  dump 

syscall  info 

syscall  table  with  hooking 
detection 

net  info 

netstat 

linux  netstat 

network  socket  list 

See  Chapter  3 

Isof 

linux  list  open  files 

open  files  list 

arehiteeture.  Table  1  summarizes  the  volafox  parsing  modules  and  offers  a  eomparison 
with  those  available  for  the  Linux  support  braneh  of  Volatility  and  tools  built-in  to  the 
OS  X  command  line.  Little  has  been  written  about  the  usage  of  volafox,  but  Shuster 
(2011)  describes  its  basic  functionality  in  his  blog. 

Revision  52  of  volafox,  the  version  extended  in  Chapter  3,  does  not  natively 
support  the  Mac  Memory  Reader  (MMR)  output  format.  Leat  (2011)  and  ATC  developer 
Hajime  Inoue  contributed  to  experimental  support  for  MMR  which  is  operational  in 
revisions  23-38  on  the  project  website.  The  feature  was  later  removed  with  the 
introduction  of  64-bit  addressing  support  due  to  compatibility  problems.  A  stand-alone 
flatten,  py  utility  authored  by  Inoue  is  still  available  to  convert  MMR  files  to  a  linear 
format,  but  only  works  for  32-bit  kernel  installations. 

An  alpha  feature  is  also  implemented  in  volafox  to  analyze  network  information, 
the  output  of  which  appears  to  be  a  simplified  version  of  the  UNIX  nets  tat  command. 
While  difficult  to  ascertain  the  state  of  this  module  given  the  lack  documentation,  in 
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limited  testing  the  feature  only  appears  to  support  IPv4  TCP  and  UDP  protoeols.  It  is  also 
unknown  whieh  kernel  structures  the  module  parses  because  this  methodology  is  not 
included  in  the  work  by  Suiche  as  with  the  others. 

2.5,3  Symbol  Table  Construction, 

In  order  to  perform  meaningful  analysis  of  raw  memory,  an  understanding  of  the 
composition  and  location  of  key  kernel  structures  is  required.  Because  Darwin  (Apple’s 
open  source  core  for  OS  X)  is  freely  available,  the  composition  of  kernel  structures  can 
be  determined  from  the  header  files  they  are  defined  in.  Locating  the  structures  in 
memory  requires  a  mapping  of  identifiers  and  offsets,  or  a  kernel  symbol  table.  Suiche 
notes  “[sjymbols  are  a  key  element  of  volatile  memory  forensics  without  them  an 
advanced  analysis  is  impossible”  (2010).  The  KPCR  structure  can  be  used  in  Windows  to 
get  the  symbols  directly  from  memory,  conveniently  this  structure  is  located  at  a  static 
offset  (Dolan-Gavitt,  2008b).  Unfortunately,  the  same  approach  cannot  be  used  on  OS  X 
because  “kernel  sections  are  destroyed  as  soon  as  the  kernel  (mach_kernel)  is  loaded  by 
removeKernelLinker  ( )  function”  [slides]  (Suiche,  2010).  A  solution  to  the 
equivalent  problem  in  Linux  is  addressed  by  Volatility,  which  maintains  a  database  of 
overlay  files  containing  the  requisite  symbol  tables  for  select  distributions  and  kernel 
versions  (Case,  2011a).  In  both  Linux  and  OS  X  therefore,  the  “easiest  way  to  retrieve 
kernel  symbols  is  to  extract  them  from  the  kernel  executable  of  the  hard-drive”  (Suiche, 
2010,  p.  4). 

Figure  1  shows  key  features  of  the  mach_kernel  executable  file,  located  at  the 
root  directory  of  the  OS  X  file  system.  Using  the  SYMTAB  load  command  structure,  a 
kernel  symbol  table  can  be  constructed  mapping  the  strings  pointed  to  by 
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fat_header 


fat_arch 
0..nfat  arch 


mach  header 


load_command: 

0..ncmds  1 


MH_MAGIC 

cputype 

cpusubtype 

filetype  \ 

ncmds 

sizeofcmds 

flags 

cmd 

cmdsize 

< - command-specific - > 

LC_SYMTAB 

cmdsize 

symoff 

nsyms 

stroff 

strsize 

niist: 

0..nsyms 


n_strx 

n_value 

n_strx 

n_value 

n_strx 

0X004EB008 

char[  strsize  ] 


\0 


\0  _kernproc\0 


Figure  1.  mach_kernel  executable. 

symtab_command .  strof  f  with  the  static  addresses  stored  in  niist .  n_value. 
Such  a  table  is  valid  for  any  installation  sharing  the  same  build  version  as  the 
mach_kernel  file  used  to  derive  it.  This  works  because  while  the  majority  of  physical 
memory  is  devoted  to  dynamic  allocation  for  use  by  running  processes,  a  portion  of  the 
layout  is  reserved  for  the  kernel  and  its  static  data  structures  (Bovet  &  Cesati,  2006). 
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In  revisions  25  and  older,  volafox  built  the  symbol  table  direetly  from 
mach_kernel  eaeh  the  tool  was  exeeuted.  This  was  inefficient  and  also  led  to  an 
undesirable  dependency  on  the  kernel  executable.  In  practice,  mach_kernel  would 
therefore  need  to  be  copied  from  a  target  when  performing  memory  acquisition.  Leat 
provided  a  patch  to  the  source,  bringing  the  overlay  functionality  available  in  the  Linux 
branch  of  Volatility  to  the  volafox  project  (Leat,  2011;  Lee,  2011).  The  current  build  (r52 
at  time  of  writing)  includes  an  overlay_generator .  py  utility  allowing  symbol 
table  generation  for  unsupported  builds  of  OS  X.  A  selection  of  overlay  fdes  is  also  being 
distributed  with  the  project.  However,  since  Apple  does  not  publish  a  comprehensive  list 
of  OS  X  build  numbers  it  is  difficult  to  know  whether  this  database  is  complete.  A  list  of 
known  builds  is  provided  in  Appendix  A,  but  it  is  recommended  that  mach_kernel 
still  be  copied  at  time  of  memory  acquisition  to  guarantee  functionality. 

2.5.4  Useful  Structures. 

The  symbol  table  provides  memory  locations  for  a  number  of  kernel  structures 
useful  in  a  forensic  examination.  The  composition  of  these  C  structures  (members  and 
their  types)  can  be  determined  via  examination  of  the  Darwin  source  code  in  which  they 
are  defined.  Suiche  (2010)  describes  several  useful  symbols  and  their  associated 
structures  as  summarized  in  Table  2.  This  work  mirrors  core  functionality  of  the  volafox 
project  so  its  equivalent  module  commands  are  also  listed  (Lee,  2011).  Note  the  proc 
structure  contains  many  additional  members  of  interest  to  be  explored  in  Chapter  3. 
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Table  2.  volafox  commands  with  associated  symbols  and  kernel  structures. 


volafox  Command 

OS  version 

Kernel  Symbol 

version 

struct  Name 

none  (points  to  100-byte  string) 

Source  Definition 

/xnu/osfmk/i38 6/lowmem  vectors . s 

Useful  Members 

operating  system,  kernel  version,  date  and  username  of  compilation 

volafox  Command 

machine  info 

Kernel  Symbol 

machine  info 

struct  Name 

machine  info 

Source  Definition 

xnu/ osfmk/mach/machine . h 

Useful  Members 

integer  t  major  version;  //  major  kernel  version 

integer  t  minor  version;  //  minor  kernel  version 

uint64  t  max  mem;  //  size  of  physical  memory 

uint32  t  physical  cpu;  //  number  of  CPU  cores 

int32  t  logical  cpu;  //  number  of  threads 

volafox  Command 

mount  info 

Kernel  Symbol 

mountlist 

struct  Name 

mount 

Source  Definition 

xnu/bsd/sys/mount  internal. h 

Useful  Members 

TAILQ  ENTRY (mount)  mnt  list;  //  linked-list  of  mounts 

struct  vfsstatfs  mnt  vfsstat; 

struct  Name 

vf sstatsf 

Source  Definition 

xnu/bsd/sys/mount . h 

Useful  Members 

char  f  fstypename;  //  file  system  type 

char  f  mntonname;  //  directory  mounted  at 

char  f  mntfromname;  //  mounted  name 

volafox  Command 

kext  info 

Kernel  Symbol 

kmod 

struct  Name 

kmod  info 

Source  Definition 

xnu/ osfmk/mach/kmod. h 

Useful  Members 

struct  kmod  info  *next;  //  next  linked  module 

int  id; 

char  name [KMOD  MAX  NAME] ; 
char  version [KMOD  MAX  NAME] ; 

int  reference  count;  //  refs  to  this  module 

vm  address  t  address;  //  starting  address 

vm  size  t  size;  //  total  size 

volafox  Command 

syscall info 

Kernel  Symbol 

nsysent 

struct  Name 

none  (points  to  an  int) 

Source  Definition 

unknown 

Useful  Members 

OS-dependent  arithmetic  required  to  find  sysent  based  on  the  address  of 
nsysent.  Suiche  (2010)  provides  detaiis  for  OS  X  10.5  and  10.6. 

struct  Name 

sysent 

Source  Definition 

xnu /bsd/sys/ sysent . h 

Useful  Members 

sy  call  t  *sy  call;  //  implementing  function 
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volafox  Command 

proc  info 

Kernel  Symbol 

kernproc 

struct  Name 

proc 

Source  Definition 

xnu/bsd/sys/proc  internal. h 

Useful  Members 

LIST  ENTRY (proc)  p  list;  //  linked-list  of  procs 

pid  t  p  pid;  //  process  identifier 

pid  t  ppid;  //  parent  pid 

char  p  comm [MAXCOMLEN+1 ] ;  //  process  name 

struct  pgrp  *p  pgrp 

struct  Name 

pgrp 

Source  Definition 

xnu/bsd/sys/proc  internal. h 

Useful  Members 

struct  session  *  pg  session; 

struct  Name 

session 

Source  Definition 

xnu/bsd/sys/proc  internal. h 

Useful  Members 

char  s  login [MAXLOGNAME] ;  //  process  username 

The  syscall  table  is  potentially  valuable  for  identifying  hooked  funetions.  Eaeh 
system  call  addresses  should  match  those  stored  on-file  in  mach_kernel,  any 
discrepancies  in  the  comparison  could  be  evidence  of  tampering  (Wowie,  2009). 
Location  of  the  sysent  structure  in  memory  changes  between  versions  of  OS  X, 
making  the  feature  difficult  to  maintain.  At  present,  the  syscall_info  command  is 
broken  in  volafox  for  10.7  captures  due  to  this  difficulty. 


2,6  Summary 

This  chapter  defined  key  terms  and  presented  the  processes  for  digital  forensics, 
incident  response,  and  memory  analysis.  Options  available  for  capturing  RAM  on  Intel 
Macs  running  OS  X  were  discussed  along  with  development  and  limitations  of  the  Mac 
Memory  Reader  tool.  A  review  of  existing  work  in  Linux  memory  analysis  was  then 
followed  by  a  description  of  the  volafox  project  being  extended  for  this  research. 
Technical  details  required  in  constructing  a  kernel  symbol  table  on  OS  X  and  several 
useful  kernel  structures  were  also  introduced. 
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III.  Methodology 


This  chapter  describes  the  implementation  of  a  new  forensic  capability  for  parsing 
open  file  information  from  OS  X  memory  captures.  When  open  files  are  mapped  to  a 
process,  the  forensic  examiner  learns  which  resources  the  process  is  accessing  on  disk. 
This  listing  is  useful  in  determining  what  information  may  have  been  the  target  for 
exfilitration  or  modification  on  a  compromised  system.  File  handles  may  also  help 
identify  a  suspicious  process  when  unexpected  fide  access  or  modifications  are  observed. 
Carvey  further  describes  how  a  list  of  open  files  can  compliment  disk  analysis  to  “get  an 
understanding  of  files  you  should  be  concerned  with  during  an  investigation”  (2009,  p. 
132).  Because  open  files  can  help  characterize  process  activity  and  highlight  misuse  of  a 
computer,  it  is  highly  desirable  to  recover  this  information  from  memory. 

A  number  of  factors  influence  the  decision  to  implement  the  feature  selected. 
First,  an  open  files  listing  is  the  first  to-do  item  on  the  volafox  project  wiki.  Second,  this 
functionality  is  already  represented  in  the  Linux  branch  for  Volatility  (Table  1).  Third,  as 
described  in  Section  2.2.2,  capturing  this  information  is  a  recommended  practice  during 
incident  response.  Listing  network  connections  was  also  considered  due  to  the  high 
forensic  value  of  this  information.  However,  because  volafox  already  includes  this  as  an 
alpha  module,  file  handles  were  determined  to  have  the  greater  research  impact. 

The  chapter  begins  with  the  design  goals  of  the  system.  Kernel  structures 
responsible  for  the  target  information  are  then  discussed.  Organization  of  the  volafox 
source  is  reviewed.  Next,  implementation  of  the  new  volafox  module  is  described  along 
with  modifications  to  the  exiting  project  source.  Finally,  the  outstanding  issues  are  listed. 
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3,1  System  Design 

The  developed  system  eonsists  of  software  for  extraeting  the  open  files  assoeiated 
with  processes  from  a  raw  memory  image  on  OS  X.  Implementation  extends  the  existing 
volafox  tool  to  parse  a  variety  of  kernel  structures  not  previously  described  in  the 
literature.  Object-oriented  design  provides  a  solution  that  is  flexible  with  respect  to  both 
kernel  architecture  and  operating  system  version. 

3.1.2.  Target  Functionality. 

The  desired  process-to-file  handle  information  is  an  approximation  of  output  from 
the  commands  Isof  for  UNIX  and  OS  X  (Apple  Inc.,  2011),  or  the  Sysinternals 
equivalent  handle  (Russinovich,  2011)  for  Windows.  Common  to  these  tools  is  the 
process  associated  with  each  handle,  a  type  classification,  and  unique  identifier.  The 
Linux  branch  of  Volatility  offers  a  possible  format  for  this  information  as  shown  in 
Figure  2.  Important  to  note  in  the  output  are  the  handle  types  for  resources  other  than 
files  on-disk,  such  as  pipes  used  for  inter-process  communication  (IPC)  and  network 
sockets. 


PID:  2095  TASK:  dl970550  CPU:  0  COMMAND:  "gdm-binary" 
ROOT:  /  CWD:  /var/gdm 


FD 

FILE 

DENTRY 

INODE 

TYPE 

PATH 

0 

dl84b300 

dl4b9dd8 

dl9b90a0 

CHR 

/ dev/ null 

1 

dl4c4380 

dl4b9dd8 

dl9b90a0 

CHR 

/ dev/ null 

2 

dOdOeSOO 

dl4b9dd8 

dl9b90a0 

CHR 

/ dev/ null 

3 

dl520500 

cf410338 

d07ff9a8 

SOCK 

socket : / [ 6645] 

4 

cca45f 00 

cbdf cb30 

ccc025d8 

PIPE 

5 

dl4c4ec0 

cf422228 

cf74bb28 

PIPE 

6 

dl407540 

dl50d800 

dl50ee40 

CHR 

/dev/console 

7 

dlbd7380 

cd59cf70 

Cf74b9d4 

PIPE 

8 

dl4eb500 

cf 12add8 

d0e83884 

REG 

/home/ stevev/ . xsession 

9 

dl4ece40 

cfl2a888 

cc0c821c 

PIPE 

11 

dl50bd80 

cbdf cb30 

ccc025d8 

PIPE 

Figure  2.  Volatility  linux_list_open_f  lies  output  (Cohen  &  Collett,  2008). 
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A  second  consideration  in  deciding  on  an  output  format  is  the  resource  available 


for  validating  the  results.  Because  the  Isof  (list  open  files)  command  is  included  with 
OS  X,  it  offers  a  convenient  and  reliable  source  of  information  for  comparison. 
Emulating  the  output  of  this  tool  not  only  simplifies  such  analysis,  it  also  gives  the 
examiner  a  familiar  interface  to  interact  with.  For  these  reasons,  Isof  was  selected  as 
the  model  for  output  format.  Figure  3  shows  sample  output  for  the  Isof  command  and 
Table  3  describes  the  information  in  each  column.  The  new  volafox  module  for  listing 
open  files  includes  functionality  for  parsing  the  nine  default  Isof  fields  present  in 
Figure  3  and  the  mode  identifier  integrated  with  the  FD  column. 


$  Isof  - 
COMMAND 

-p  109 
PID 

USER 

FD 

TYPE 

DEVICE 

SIZE/OFF 

NODE 

NAME 

bash 

109 

Gad 

cwd 

DIR 

14,2 

578 

202041 

/Users/Gad 

bash 

109 

Gad 

txt 

REG 

14,2 

134G544 

2G2558 

/bin/bash 

bash 

109 

Gad 

txt 

REG 

14,2 

10549G0 

2G4388 

/usr/lib/dyld 

bash 

109 

Gad 

txt 

REG 

14,2 

21338521G 

4GG405 

/private/var /db/ 

bash 

109 

Gad 

Ou 

CHR 

IG,  0 

0t3G9 

Gil 

dyld/dyld  shared 
cache  x8G  G4 
/dev/ttysOOO 

bash 

109 

Gad 

lu 

CHR 

IG,  0 

0t3G9 

Gil 

/dev/ttysOOO 

bash 

109 

Gad 

2u 

CHR 

IG,  0 

0t3G9 

Gil 

/dev/ttysOOO 

bash 

109 

Gad 

255u 

CHR 

IG,  0 

0t3G9 

Gil 

/dev/ttysOOO 

Figure  3.  FTNIX  list  open  files  (Isof)  command. 
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Table  3.  UNIX  Isof  output  fields. 


COMMAND 

First  nine  characters  of  the  UNIX  command  associated  with  the  process. 

PID 

Process  identification  number. 

USER 

Login  name  of  the  user  to  whom  the  process  belongs. 

FD 

File  descriptor  is  a  numeral  index  into  the  process  open  handle  array  optionally 
followed  by  a  mode  identifier:  r  (read  access),  w  (write  access),  or  u  (both).  Two 
other  descriptors  commonly  seen  are  cwd  representing  the  current  working 
directory  for  the  process  and  txt  used  for  program  text  (code  and  data).  These 
files  are  of  high  forensic  value  because  they  include  the  executable  from  which 
the  command  was  launched,  linked  libraries,  and  other  memory-mapped  files. 

See  the  output  section  of  the  isof  manpage  for  a  full  list  of  descriptors  used 
(Apple  Inc.,  2011). 

TYPE 

Node  type  associated  with  the  handle.  See  the  output  section  of  the  isof 
manpage  a  partial  type  listing  (Apple  Inc.,  2011).  Note  that  numerous 
undocumented  types  were  encountered  in  testing  such  as  FSEVENT. 

DEVICE 

Major  and  minor  device  numbers  separated  by  a  comma.  The  first  number 
describes  a  class  of  hard/software  device  and  the  second  is  a  unique  identifier 
for  a  particular  instance  of  that  class. 

SIZE/OFF 

Size  or  offset  of  a  file  reported  in  bytes.  Offsets  are  preceded  by  a  leading  ot  to 
distinguish  when  the  column  is  mixed. 

NODE 

The  node  number  for  a  local  file.  This  unique  identifier  is  filesystem  dependent. 

For  example,  files  stored  on  HFSh-  report  the  catalog  node  identifier  (CNID)  for 
this  field,  whereas  DEVFS  files  use  a  UNIX  inode  number  instead. 

NAME 

Mount  point  and  file  system  on  which  a  file  resides,  or  name  of  character  special 
device. 

3.1.3  Implementation  Constraints. 

While  an  ideal  implementation  would  fully  duplieate  the  functionality  and 
nuances  of  the  Isof  command,  the  diversity  of  data  structures  required  to  accomplish 
this  makes  it  impractical  with  the  development  resources  available  for  this  research.  A 
design  choice  is  made  to  focus  on  file  rather  than  socket  or  IPC  handles  for  this  research 
due  to  the  forensic  value  of  the  information  and  because  file  handles  logically  divide  the 
development  workload.  Constraints  of  the  tool  implemented  are  formalized  in  Chapter  4, 
but  there  are  two  key  decisions  that  influence  the  implementation. 
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First,  the  volafox  open  files  module  supports  a  subset  of  handle  types,  and  only 
those  subseribing  to  the  virtual  node  (vnode)  interfaee.  The  exeluded  types  mean  POSIX 
semaphores  and  shared  memory  files,  kernel  event  queue  files,  pipes,  and  soekets  are 
reported  as  part  of  the  file  deseriptor  table,  but  with  DEVICE,  SIZE/OEE,  NODE  and 
NAME  fields  unsupported.  Additionally,  the  ETNIX  Isof  eommand  elassifies  soekets  by 
a  variety  of  subtypes  that  the  volafox  open  files  module  groups  together  using  the  generic 
description  ‘SOCKET’  in  the  TYPE  field. 

Second,  the  module  supports  a  subset  of  the  filesystems  available  for  OS  X, 
specifically  HES+  and  DEVES.  HES+  is  the  default  format  for  the  OS  X  boot  volume  and 
DEVES  is  used  to  abstract  certain  devices,  such  as  special  character  files.  Among  other 
uses,  special  character  files  describe  ttys  devices  controlling  the  print  streams  stdin, 
stdout,  and  stderr  of  terminal  programs.  HES+  and  DEVES  account  for  the 
filesystems  most  commonly  encountered  during  development  and  testing,  but  the  vnode 
interface  makes  reference  to  at  least  20  other  types.  One  impact  of  this  constraint  is  that 
files  stored  on  network  filesystems,  EAT32,  NTES  and  others,  do  not  have  volafox 
support  for  Isof  fields  outside  the  vnode  interface. 
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3,2  Key  Kernel  Structures 

This  section  documents  the  kernel  design  recovery  research  objective  specified  in 
Section  1.1.  Implementing  the  new  volafox  module  for  listing  open  files  requires 
knowledge  of  32  unique  C  data  structures  from  the  OS  X  source  code,  four  of  which  are 
described  by  Suiche  (2010)  to  list  running  processes.  These  include  26  structure  (struct), 
three  enumeration  (enum),  and  three  union  definitions.  Identifying  the  data  structures 
containing  critical  information  and  the  relationships  between  them  is  one  of  the  primary 
contributions  of  this  research  because  “the  kernel  isn’t  heavily  commented  and  its 
internals  aren’t  documented,  so  you  learn  by  tracing  code  by  hand”  (Sesek,  2012).  Figure 
4  shows  an  overview  of  the  relevant  structures  and  associated  UNIX  Isof  fields  from 


Table  3.  The  names,  source  files,  interesting  members,  and  relationships  between  these 
data  structures  appear  as  series  of  relationship  diagrams  in  Figures  5-8  and  Appendix  B. 


Figure  4.  C  struct  relationship  overview. 
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Extracting  open  file  information  begins  with  the  kernel  symbol  table,  shown  in 
Figure  5  and  deseribed  in  Section  2.5.3.  Symbol  _kernproc  provides  an  address  for  the 
head  of  the  proeess  list,  kerne  l_t  ask  (PID  0),  whieh  is  unique  in  its  use  of  statie  data 
struetures  (Singh,  2006b,  p.  293).  Beeause  of  this  property,  PID  0  does  not  appear  in  the 
output  of  UNIX  eommands  sueh  as  ps  or  Isof  and  therefore  is  exeluded  from  the  file 


handles  module  implementation.  The  COMMAND  and  PID  fields  are  members  of 
struct  proc,  and  USER  is  loeated  in  struct  session.  Note  that  p_list  is  a 
substrueture,  meaning  proc  eontains  it  as  a  member  rather  than  using  a  pointer  to 
referenee  it. 


/mach_kernel 


Figure  5.  Symbol  table  and  proeess  list. 
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Structure  task,  as  pointed  to  by  proc  in  Figure  5,  provides  the  link  to  program 
text  files  (FD  txt).  Program  text  refers  to  the  code  and  data  segments  of  an  executable, 
as  well  as  linked  libraries  and  any  other  memory-mapped  files.  This  information  is 
invaluable  for  identifying  rouge  processes,  whieh  often  masquerade  as  legitimate 
executables  to  avoid  detection  (SANS  Institute,  2008). 

Figure  6  shows  how  these  files  are  refereneed.  Structure  _vm_map  stores  the 
header  for  a  ring  of  vm_map_entry  structures  eontaining  the  union  member  object. 
Eaeh  memory  object  may  reference  a  struct  vm_object  or  reeursively  refer  to 
another  entry.  Memory  mapped  files  are  backed  by  a  vnode  pager,  but  the  pager  may  be 
located  in  the  shadow  object  for  external  memory  managers  (Singh,  2006b,  p.  571). 


Figure  6.  Memory-mapped  files  (txt). 
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The  file  deseriptor  table  and  eurrent  working  direetory  are  refereneed  from 
struct  filedesc  as  shown  in  Figure  7.  Member  f  iledesc .  f d_of  iles  is  a 
pointer  to  the  start  of  a  fileproc  array.  Elements  of  the  array  that  eontain  a  valid 
f  ileglob  pointer  reference  a  handle,  those  that  do  not  are  available  to  hold  one.  The 
index  into  this  array  represents  the  numerical  file  identifier  used  by  the  FD  field  of  the 
Isof  output.  Integer  filedesc.  fd_lastfile  indexes  the  last  file  in  the  array  and 
provides  an  iteration  bound.  The  array  itself  makes  up  the  file  descriptor  table,  used  by  a 
process  to  reference  all  open  files  (ASCII,  word  processing,  logs,  temp,  etc.).  File  mode, 
or  read/write  access,  is  determined  from  the  value  of  f ileglob.  fg_flag  using  the 
bitmap  definitions  in  bsd/sys/f  cntl .  h.  Member  f  ileglob .  fg_off  set  is  the 
offset  for  FIFO  and  special  character  files  as  reported  in  the  Isof  SIZE/OFF  field.  The 


Figure  7.  File  descriptor  table. 
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f  ileglob .  f  g_data  member  is  a  generie  pointer  that  may  referenee  a  variety  of 
struetures.  As  deseribed  in  Seetion  3.1.3,  full  support  is  eonstrained  to  vnode  types. 
Enumerator  f  ileglob  .  fg_type  holds  destination  type  of  the  pointer.  Any  non-vnode 
handle  ean  be  typed  using  the  values  of  enum  file_type_t,  but  DEVICE, 
SIZE/OEE,  NODE  and  NAME  fields  are  unsupported  for  sueh  handles  using  this 
research  implementation. 

Eigure  8  shows  the  struct  vnode  referenced  by  proc,  vnode_pager, 
f  iledesc  and  f  ileglob  structures  shown  in  Eigures  5-7.  The  Isof  NAME  field  is  a 
concatenation  of  the  device  name  from  mount .  vf  sstatf  s  .  f_mntf  romname  and  a 
path  of  vnode.  v_name  strings  recursively  references  using  vnode .  v_parent. 
Member  vnode. vtype  describes  the  fide  type  of  any  supported  file,  and 
vnode  .  v_tag  holds  the  associated  filesystem.  The  number  of  combinations  created  by 
vnode. v_type  and  vnode. v_tag  leads  to  branches  at  union  v_un  and  the 
generic  pointer  v_data.  NODE  is  stored  at  devnode .  dn_ino  for  all  files  using  the 
VT_DEVES  filesystem  and  in  cnode .  cat_desc .  cd_cnid  for  VT_HES.  An 
encoded  device  identifier  is  found  at  specinfo .  si_rdev  for  VT_DEVES  and  in 
mount .  vf  sstatf  s  .  fsid .  val  [0]  for  VT_HES.  The  device  identifier  is  decoded 
using  macros  in  bsd/sys/types . h  that  return  major  and  minor  device  numbers. 
Returning  the  correct  Isof  SIZE/OEE  value  requires  knowledge  of  vnode  .  v_type. 
Eor  VREG  files  the  size  is  found  in  ubc_info  .  ui_size,  however  this  structure  is  not 
valid  for  system  vnodes  that  are  otherwise  regular  (Singh,  2006b,  p.  605). 
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vnode_pager 

filedesc 

fileglob 

9 

vnode_handle  <? 

fd_cdir  Q 

fg_data  q 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

bsd/sys/vnode.h 
«  enum  » 

vtype 

VNON 


bsd/sys/vnodejnternal.h 

_ vnode _ 

-  v_type 

-  v_tag 


bsd/miscfs/specfs/specdev.h 

_ specinfo _ 

si  rdev 
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VDIR  file  size  is  ealculated  using  the  count  in  cnode .  cat_attr .  cau_entries, 
the  equation: 

(entries  +  2)  *  AVERAGE_HFSDIRENTRY_SIZE 
found  in  bsd/hf  s/hf  s_vnops  .  c,  and  the  macro  definition  from  bsd/hf  s/hf  s  .  h. 
Finally,  VLNK  sizes  are  located  in  f  ilefork .  cat_fork .  cf_size. 

Starting  with  the  address  pointed  to  by  _kernproc,  this  section  describes  the 
structures  and  relationships  for  retrieving  information  needed  to  emulate  Isof  output 
for  all  vnode  type  files  stored  on  HFS+  or  DEVFS  filesystems.  Table  4  summarizes  the 
structure  members  needed  to  support  the  required  fields. 


Table  4.  Open  file  data  locations. 


!  DTYPE 

_VNODE 

DTYPE_VNODE 

VT_HFS 

VT_DEVFS 

VREG 

VDIR 

VLNK 

VFIFO 

COMMAND 

proc.p  comm 

PID 

proc.p  pid 

USER 

session. s  login 

FD  &  mode 

filedesc.fd  ofiles[i]  +  fileglob.fg  flag 

TYPE 

f ileglob . 
fg  type 

vnode. V  type 

DEVICE 

■ 

mount . vf sstatf s . f sid . val [ 0 ] 

specinf o . 

si  rdev 

SIZE/ 

OFF 

ubc  info. 

ui  size 

cnode . 

cat  attr. 

cau  entries 

f ilefork . 

cat  fork. 

cf  size 

f ileglob . 
fg  offset 

NODE 

cnode . cat  desc.cd  cnid 

devnode . 

dn  ino 

NAME 

mount . vf sstatf s . f  mntfromname  + 

recurse (vnode . V  parent->v  name)  +  vnode. v  name 
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3.2.1  OS  X Abstraction  Layers. 

OS  X  is  a  commercial  operating  system  integrating  a  collection  of  technologies,  a 
subset  of  which  are  made  open  source  by  the  Darwin  UNIX  distribution.  This  research  is 
concerned  with  data  struetures  defined  by  the  Darwin  kernel,  known  as  xnu.  The  xnu 
kernel  is  eomposed  of  several  additional  abstraction  layers.  Maeh,  sometimes  described 
as  the  xnu  mierokernel,  provides  eritical  low-level  serviees.  These  are  leveraged  by  BSD, 
“the  primary  system  programming  interfaee”  (Singh,  2006b,  p.  31).  Among  other 
features,  the  BSD  layer  supports  a  proeess  model  and  virtual  file  system  (VFS)  layer. 
BSD  hooks  into  Maeh  for  numerous  services,  such  as  task  operations  responsible  for 
exeeution  and  the  virtual  memory  subsystems  (Singh,  2006b,  p.  33). 

Much  of  the  preceding  design  recovery  is  a  eonsequenee  of  manual  inspection  of 
the  Darwin  source  code  and  headers,  eombined  with  prototype  development  in  volafox  to 
verify  the  purpose  of  various  structure  members.  However,  there  are  several  instanees 
where  the  destination  of  a  pointer  referenee  is  of  unknown  or  ambiguous  type, 
eomplieating  this  analysis  considerably.  Figure  9  demonstrates  the  problem  using 
struct  proc.  While  three  of  the  members  shown  are  explieitly  typed,  such  as  pid_t 
p_pptr,  the  strueture  pointed  to  by  task  is  unknown  using  the  definition  alone. 
Similar  issues  occur  at  vm_ob  j  ect .  pager,  f  ileglob  .  f  g_data,  vnode.  v_un 

struct  proc  { 

LIST_ENTRY (proc)  p_list; 
pid_t  p_pid; 

void  *  task;  /*  corresponding  task  (static)*/ 

struct  proc  *  p_pptr; 

}; 

Figure  9.  struct  proc. 
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and  vnode .  v_data.  These  generic  object  pointers  appear  at  locations  where  an 
interface  is  needed  between  two  or  more  different  abstraction  layers.  In  the  example, 
struct  proc  is  a  BSD  structure  and  proc .  task  points  to  a  Mach  structure.  Figure 
10  summarizes  the  relevant  layer  interfaces.  Note  that  while  f  ileglob  .  f  g_data  only 
branches  back  into  the  BSD  layer  for  this  implementation,  support  for  additional  file 
types  would  involve  structures  such  as  those  for  pipes  and  sockets  that  may  exist  outside 
the  BSD  abstraction  layer  (Singh,  2006b,  p.  919). 


bsd/sys  osfmk 


Figure  10.  Abstraction  crossover. 


3,3  Project  Volafox 

This  section  describes  software  design  details  of  the  volafox  project  needed  to 
understand  implementation  of  the  new  open  file  listing  module.  First,  the  relevant  source 
files  and  Python  classes  are  introduced.  Next,  the  execution  flow  for  the  main  project  file 
is  traversed  to  explain  where  the  new  module  interfaces  with  the  existing  code. 
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3.3.1  Package  Organization 

Figure  1 1  shows  a  summary  of  the  souree  files  from  the  volafox  paekage  related 
to  OS  X  memory  analysis.  Publie  elasses  in  eaeh  file  are  indieated  in  bold.  Conneetions 
represent  file  dependeneies,  whieh  are  labeled  with  the  publie  funetion  names.  The  new 
open  fdes  module,  Isof  .  py,  is  shown  but  not  diseussed  until  Seetion  3.4. 


x86.py 

ia32_pml4.py 
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Main  program  execution  depends  on  the  following  source  files  and  directory: 

addrspace . py  -  houses  FileAddressSpace  class  responsible  for  file  operations 
on  linear  memory  images. 

macho. py  -  support  for  the  Mac  Memory  Reader  image  format  (Mach-0),  the 
MachAddress Space  class  is  written  to  be  the  MMR  format  equivalent  of 
FileAddressSpace.  As  of  revision  48  of  the  project  this  functionality  was 
disabled  due  to  compatibility  problems  with  64-bit  analysis. 

x8  6.py  /  ia32_pml4.py  -  these  files  house  the  address  space  agnostic  classes 
IA32PagedMemoryPae  and  IA32PML4MemoryPae  respectively.  They  are 
responsible  for  performing  virtual  to  physical  address  translations  that  can 
subsequently  be  converted  to  file  offsets  by  either  FileAddressSpace  or 
MachAddress  Space  (whichever  is  passed  to  the  initializer).  All  requests  for 
reading  raw  memory  are  passed  through  one  of  these  two  objects.  PML4  is  a 
reference  to  the  4^*'  level  page  map  used  by  the  Intel  IA-32e  paging  scheme  (Intel 
Corporation,  2012),  meaning  the  second  file  is  the  one  responsible  for  handling 
64-bit  architecture  images  where  the  first  is  used  for  32-bit. 

imageinfo.py  -  the  imageinfo  class  inspects  a  memory  image  file  to  determine 
the  file  format  (MMR  or  linear)  and  kernel  architecture  (32  or  64-bit)  required  to 
initialize  the  correct  address  space  and  PAE  objects  already  described.  It  also 
returns  the  OS  X  build  version  information  for  the  image  needed  to  select  the 
correct  overlay  file.  This  file  also  has  a  main  so  it  can  be  executed  as  a  stand¬ 
alone  utility. 

Usage:  $  python  imageinfo.py  IMAGE. mem 

overlays  /  -  as  of  revision  48,  volafox  .py  no  longer  accepts  a  mach_kernel  file 
argument  for  building  the  symbol  table.  All  symbols  are  read  from  files  in  the 
overlays  directory  labeled  by  OS  version  and  architecture  using  the  Python 
pickle  library  for  object  serialization.  New  overlays  can  be  generated  from  the 
kernel  executable  with  the  overlay_generator  .  py  utility. 

volafox. py  -  houses  the  project  main()  and  class  volafox  responsible  for 
marshaling  the  remaining  files  and  classes  to  preform  analysis  of  OS  X  memory 
images. 

Usage:  $  python  volafox. py  -i  MEMORY_IMAGE 

[-0  INEORMATION] [-m  KEXT  ID] [-x  PID] 
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The  volafox  package  also  includes  several  stand-alone  utilities: 


showbootermemorymap .  py  -  outputs  the  load  commands  from  an  MMR  image  in 
the  same  format  as  the  showbootermemorymap  kernel  macro  debug  script 
and  the  /dev/pmap  device. 

Usage:  $  python  showbootermemorymap  .  py  IMAGE,  mmr 

flatten. py  -  converts  MMR  image  files  from  Mach-0  into  a  linear  equivalent  which 
can  be  analyzed  by  volafox.py.  This  script  is  only  operable  on  32-bit 
architecture,  as  verified  using  the  imageinf  o  .  py  utility. 

Usage:  $  python  flatten. py  SOURCE. mmr  DEST.flat 

overlay_generator  .  py  -  reads  the  symbol  table  from  a  mach_kernel  executable 
and  stores  to  file  in  the  form  of  a  serialized  Python  dictionary  for  use  in  the 
overlays  directory. 

Usage:  $  python  overlay_generator  .  py  MACH_KERNEL 
10 .MAJOR. MINOR_ARCH. overlay  [32 | 64] 


3.3.2  Module  Interface. 

As  summarized  in  Table  1,  volafox  features  a  number  of  command  options  for 
parsing  information  from  raw  memory.  The  code  implementing  these  branches,  around 
1300  lines,  is  contained  within  the  source  file  volafox.py.  This  monolithic  software 
design  is  not  particularly  modular,  but  the  implementation  of  the  new  open  files 
functionality  strives  to  be.  This  section  explains  where  the  new  code  interfaces  with  the 
existing  project. 

Since  volafox  .  py  is  intended  to  be  run  in  Python  executable  mode,  the  support 
code  of  concern  begins  in  main  ( ) .  This  function  performs  the  following  actions: 

1 .  Handle  command  line  arguments  and  the  usage  statement. 

2.  Instantiate  a  new  volafox  object  with  path  to  the  raw  memory  image  file. 
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3.  Delegate  to  volafox  object  for  initialization  of  the  correct  address  space  and 
PAE  objects,  a  method  that  also  returns  the  architecture  and  OS  version  needed  to 
select  the  correct  overlay  file. 

4.  Import  a  symbol  table  as  a  Python  dictionary  from  the  correct  overlay  stored  on 
file  as  a  serialized  object. 

5.  Pass  addresses  for  the  _IdlePDPT  and  _IdlePLM4  symbols  to  the  volafox 
object,  which  uses  them  to  initialize  the  page  table  map  and  thereby  completes 
setup  for  virtual  to  physical  address  translation. 

6.  Pass  address  for  the  _machine_inf o  symbol  to  the  volafox  object,  which 
uses  it  to  determine  the  kernel  version  and  stores  the  result  as  an  instance  variable 
for  branching  based  on  OS  (Lion  versus  Snow  Leopard). 

7.  Branch  based  on  user  information  requested  to  call  the  appropriate  class 
volafox  method.  Each  information  method  accepts  a  kernel  symbol  address  and 
returns  a  string  matrix  of  results. 

8.  Print  results  and  exit. 

The  new  module  adds  code  to  main  ( )  for  additional  argument  handling  and  a  branch 
for  calling  a  new  Isof  method  in  class  volafox.  Method  Isof  branches  on 
architecture  to  correctly  read  and  unpack  the  _kernproc  symbol  and  delegates  all  other 
open  file  analysis  to  the  new  source  file  1  sof  .  py  shown  in  Ligure  1 1 . 


3,4  File  Handle  Module  Implementation 

This  section  introduces  a  new  file  handle  module  for  volafox  revision  52.  Lirst, 
the  Unified  Modeling  Language  (UML)  is  used  to  present  a  graphical  view  of  how  the 
new  Isof  .  py  source  file  is  organized  in  Ligures  12-13  and  Appendix  E.  The  solution  to 
flexible  analysis  of  multiple  kernel  architecture  and  OS  versions  follows.  Next,  the  issue 
of  ambiguous  data  types  is  discussed.  Linally,  modifications  to  the  existing  volafox 
source  code  are  listed. 
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3.4.1  Object-oriented  Design. 

While  the  open  files  module  does  not  require  a  complex  inheritance  hierarchy,  a 
class  diagram  still  offers  the  best  visual  explanation  of  the  software’s  design.  UML  is 
therefore  used  to  provide  an  overview  of  the  Isof .  py  source  fide,  the  complete  version 
of  which  is  available  as  a  single  graphic  in  Appendix  D.  Some  liberty  has  been  taken  with 
the  standard  since  the  source  integrates  both  object-oriented  and  imperative  programming 
elements.  Note  that  aggregate  associations  are  modeled  when  a  class  definition  includes 
an  explicit  instance  variable  of  another  class,  while  dependencies  are  used  if  a  class 
constructs  instances  for  use  only  within  method  scope. 

Figure  12  shows  the  class  elements  corresponding  to  structures  of  the  process  list 
and  the  file  descriptor  table.  It  also  specifies  the  abstract  superclass  Struct,  the  parent 
of  all  remaining  classes  in  Isof  .py.  Figure  13  covers  structures  related  to  the  vnode 
interface  and  memory-mapped  files.  The  utilities  box  describes  global  variables  and 
function  dependencies  outside  the  class  hierarchy.  The  Isof  .py  box  shows  imperative 
functions  which  depend  on  the  classes,  including  the  public  getfilelistO  and 
printfilelist  (),  which  serve  as  an  interface  to  the  remaining  volafox  source  code. 
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Filedesc 


-TEMPLATES  :  diet 


+ _ init _ (addr :  int) 

+getcwd() :  int  {  pointer } 
+getfglobs()  ;  diet 


+ _ init _ (addr :  int) 

+getmode(fd  :  int)  :  str 
+gettype()  :  str 
+getoff():  int 

+getdata():  int  {  pointer } 


Pgrp 

-TEMPLATES 

:  diet 

+ _ init _ (addi 

+getuser()  :  st 

r :  int) 
r 

\  I 


+getfilelist(  mem  :  IA32*MemoryPae,  areh  :  int,  kvers  :  int, 

proe_head  :  int  {  pointer },  pid  :  int,  vflag  :  int )  :  list 
+printfilelist(filelist :  list) 

-getfilelistbyproe(proe  :  Proe)  :  list 

-eolumnprint(  headerlist :  list,  eontentlist :  list,  mszlist :  list  =  [1 ) 


Task 


— _ Proc _ 

+self_ptr :  int  {  pointer } 
-TEMPLATES  :  diet 
-head  :  int  {  pointer } 
-filedese_ptr :  int  {  pointer } 
-exe_ptr :  int  {  pointer } 

.  -pgrp_ptr ;  int  {  pointer } 

-pid:  int _ 

+ _ init _ (int) 

+next()  :  Proe 
+valid()  :  bool 
+setpid()  :  bool 
+getfd()  :  int  {  pointer } 
+getpid()  :  int 
+getemd()  :  str 
+getuser() :  str 
+gettxt()  :  list 


Figure  12.  UML  1  -  process  list  and  file  descriptors. 


50 


+ _ init _ (addr :  int) 

+gettxt()  :  list _ 


Vm_map 

-TEMPLATES  :  diet 

+ _ init _ (addr :  int) 

-i-gettxt()  :  list 

I 


Vm_map_entry 

-TEMPLATES  :  diet 

+ _ init _ (addr :  int) 

+getnext()  :  int  {  pointer } 
+gettxt()  :  list _ 


Task 

-TEMPI  ATES 

diet 

+ _ init _ (addr 

int) 

-i-gettxt()  :  list 

Mount 


-TEMPLATES  :  diet 


+ _ init _ (addr :  int) 

H-getmountO  :  str 
+getdev()  :  str _ 


Figure  13.  UML  2  -  vnode  interfaee  and  memory -mapped  files. 
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Though  Python  is  not  a  strictly  object-oriented  language,  its  support  for  classes 
allows  for  a  modular  implementation  that  maps  to  the  network  of  kernel  structures 
previously  discussed.  Because  C  structs  group  data  types,  a  natural  solution  to  parsing 
their  content  uses  object  instances  as  containers  for  the  address  space  they  occupy  and 
class  methods  for  handling  the  unpacked  data  (see  Appendix  C.  Python  struct 
Library).  The  open  files  module  defines  classes  for  18  of  the  structures  described  in 
Section  3.2,  the  remaining  substructures  are  handled  inside  the  class  methods  since  they 
occupy  the  address  space  of  the  struct  in  which  they  are  defined. 

3.4.2  Structure  Templates. 

Sections  3.4.2  -  3.4.5  collectively  document  the  research  objective  from  Section 
1.1  that  requires  a  flexible  process  for  programmatically  handling  kernel  data  structures 
defined  for  different  kernel  architectures  and  operating  system  versions.  Existing  volafox 
modules  are  not  readily  extensible  and  require  additional  logic  branching  for  each  variant 
in  size  or  composition  of  the  underlying  kernel  data  structures.  The  module  implemented 
for  this  research  uses  a  dynamic  runtime  solution  consisting  of  two  parts. 

First,  the  following  interface  is  defined  to  describe  required  members  of  each 
structure  for  a  given  architecture  and  OS  version: 

template  =  {  MBR_NAME  :  (  MBR_TYPE,  OFFSET,  SIZE,  FIELD, 

SUB  STRUCT  ),...} 
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Table  5.  Template  interfaee  fields. 


Variable 

Python 

Type 

Description 

template 

diet 

template  implementing  the  C  stuet  interfaee 

MBR  NAME 

str 

dietionary  key,  variable  name  for  a  struet  member 

template [MBR  NAME] 

tuple 

dietionary  value,  a  struet  member  deseription 

MBR  TYPE 

str 

C  type  of  the  named  member 

OFFSET 

int 

offset  in  bytes  for  the  member 

SIZE 

int 

size  in  bytes  for  the  member  type 

FIELD 

str 

Isof  field  represented  by  member 

SUB  STRUCT 

diet 

reeursively  defined  substructure  {optional) 

Table  5  lists  Python  types  from  the  C  struet  template  interfaee,  whieh  itself  is 
implemented  as  a  dietionary.  Substruetures  are  defined  as  those  eontained  within  the 
memory  alloeated  for  a  super  structure.  They  share  the  same  dictionary  format  as  regular 
structures  and  their  values  are  referenced  recursively.  Figure  14  shows  the  32-bit  Snow 
Leopard  variant  for  the  struct  proc  template. 


template  =  { 

'p_list'  :  (  'LIST_ENTRY (proc) ' ,  0,  8,  ,  { 

' le_next '  :  (  'struct  proc  0,  4,  ''  ), 

'le_prev'  :  (  'struct  proc  **',  4,  4,  ''  ) 

} 

)  , 

'p_pid'  :  (  'pid_t',  8,  4,  'PID'  ), 

'task'  :  (  'void  * ' ,  12,  4,  '  '  )  , 

'p_fd'  :  (  'struct  filedesc  *',  104,  4,  ''  ), 

'p_textvp'  :  (  'struct  vnode  *',  388,  4,  ''  ), 
'p_comm'  :  (  ' char [ ] ' ,  420,  17,  'COMMAND'  ), 

'p_pgrp'  :  (  'struct  pgrp  *',  472,  4,  ''  ) 

} 


Figure  14.  struct  proc  template,  10.6  x86. 


The  second  component  in  the  template  solution  is  a  Python  class  initializer  that 
dynamically  selects  the  correct  template  for  a  given  subclass  at  runtime  based  on  the  OS 
version  and  architecture  of  the  memory  image  under  analysis.  Because  classes  in  the  open 
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files  module  manage  fields  and  methods  assoeiated  with  a  partieular  kernel  structure,  all 
inherit  from  the  abstract  superclass  in  Figure  15. 


class  Struct (object) : 

mem  =  None 

ver  =  False 

arch  =  -1 

kvers  =  -1 

TEMPLATES  =  None 
template  =  None 
ssize  =  -1 

def  _ Inlt _ (self,  addr) : 

If  self. _ class _ .template  ==  None: 

self. _ class _ .template  =  self. _ class _ . TEMPLATES [ Struct . arch]  \ 

[ Struct . kvers ] 


for  item  in  self. _ class _ . template . values () : 

if  (  item[l]  +  item[2]  )  >  self. _ class _ .ssize: 

self. _ class _ .ssize  =  item[l]  +  item[2] 

self.smem  =  Struct .mem. read (addr,  self. _ class _ .ssize); 


Figure  15.  Simplified  abstract  class  Struct  (no  error  handling). 


The  first  four  static  variables  belong  to  the  abstract  class  and  are  shared  by  all 
Struct  subclasses.  The  mem  variable  is  a  reference  to  one  of  the  PAE  objects  described 
in  Section  3.3.1.  Verbose  flag  ver  indicates  if  all  file  descriptors  should  be  printed, 
including  those  for  types  not  fully  supported  by  the  open  files  module.  The  arch  and 
kvers  variables  report  the  kernel  architecture  and  version  respectively.  The  final  three 
fields  are  virtual  static  variables  because  their  assignment  is  deferred  to  the  subclasses. 
The  constant  TEMPLATES  is  a  nested  dictionary  from  which  the  static  template  is 
assigned  the  first  time  the  initializer  runs  based  on  value  of  arch  and  kvers.  The  static 
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ssize  is  subsequently  assigned  based  on  the  seleeted  template  and  determines  how 
many  bytes  the  initializer  reads  from  the  address  passed  as  an  argument  to  provide 
coverage  of  all  members  specified  in  the  structure  template. 

Combining  the  structure  template  interface  with  an  abstract  initializer  offers  a 
solution  that  greatly  simplifies  the  program  logic  needed  to  support  a  selection  of 
architectures  and  OS  versions.  The  result  is  also  highly  extensible  because  new  templates 
can  be  added  without  any  code  refactoring  as  long  as  the  member  names  remain 
consistent  across  versions.  Figure  16  shows  the  concrete  subclass  corresponding  to 
struct  devnode  and  demonstrates  use  of  the  structure  template  solution. 


class  Devnode (Struct) : 

TEMPLATES  =  { 

32  :  { 

10 : { 'dn_lno ' : ( ' lno_t ',112,4, 'NODE ' ) } 

,  11 : { 'dn_ino ' : ( ' lno_t ',112,4, 'NODE ' ) } 

}, 

64  :  { 

10 : { ' dn_lno ' : ( ' lno_t ',192,8, ' NODE ' ) } 

,  1 1 : { ' dn_lno ' : ( ' lno_t ',192,8, ' NODE ' ) } 

} 

} 


def  _ Init _ (self,  addr) : 

super (Devnode,  self) . _ init _ (addr) 

def  getnode (self ) : 

return  unpacktype ( self . smem,  self . template [' dn_ino '] ,  INT) 


Figure  16.  Concrete  class  Devnode. 


3.4.3  Member  Offsets  and  Type  Sizing. 

While  the  dictionary  constants  used  to  implement  structure  templates  are  easy  to 
work  with  programmatically,  generating  their  syntax  is  labor  intensive.  The  open  files 
module  uses  (18  classes  *  2  versions  *  2  architectures)  =  72  struct  templates,  requiring  a 
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great  deal  of  error-prone  eoding  and  debugging  if  generated  by  hand.  Determining  size 
and  offset  values  for  each  member  in  the  template  is  also  very  difficult  to  accomplish 
manually  due  to  the  complexity  of  defined  types  included  in  the  kernel  structures.  The 
solution  to  both  of  these  challenges  is  an  external  C  program  that  dissects  kernel 
structures  and  automates  the  generation  of  the  Python  dictionary  syntax  needed  for  each 
template. 

The  offsets. c  program  was  developed  to  find  the  size  and  offset  of  each 
required  structure  member  and  print  the  results  as  a  structure  template  for  use  in 
Isof  .py.  Figure  17  shows  a  function  from  the  program  that  prints  a  template  for 
struct  _vm_map.  The  variable  member  is  a  C  structure  defined  in  the  program  to 
hold  the  fields  described  in  Table  5  and  printmember  ( )  formats  each  as  a  key/value 
pair  for  the  enclosing  Python  dictionary.  The  argument  mh  is  a  function  pointer  to  a 
substructure  that  is  printed  recursively. 


int  vm_inap  ( )  { 

member  m; 

int  (*mh) (unsigned  long  int  offset)  =  &vm_map_header; 
printf ( " struct_vmmap  =  {"); 
m.var_name  =  "hdr"; 

m.var_type  =  "struct  vm_map_header " ; 
m. offset  =  of fsetof ( struct  _vm_map,  hdr) ; 
m.size  =  sizeof  (struct  vm_map_header); 
m . field  =  " " ; 
printmember (m,  mh) ; 

printf  (  " } \n" ) ; 
return  0; 


Figure  17.  Template  generation  function. 
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The  C  language  sizeof  operator  is  used  to  find  the  size  of  any  type,  and  the 

preproeessing  maero  offsetof  defined  in  stddef  .h  ean  return  the  offset  of  any 

member  for  a  given  strueture.  However,  most  of  the  header  files  defining  the  struetures 

deseribed  in  Section  3.2  are  not  available  in  the  include  path  for  OS  X.  Sesek  (2012) 

explains  the  problem  and  suggests  a  workaround  in  a  blog  post  about  kernel  debugging: 

Structs  [...]  are  merely  human-friendly  offsets  into  a  region  of  memory. 

Their  definition  and  layout  can  be  shamelessly  copied  from  the  XNU  open 
source  headers  into  your  kext’s  project  so  that  you  can  access  fields  in 
kernel  private  structures.  As  it  turns  out,  virtually  ever  structure  within  the 
kernel  is  designed  to  be  opaque  to  a  kext.  Apple  decided  to  do  this  so  that 
they  can  freely  change  the  kernel  structures,  but  it  also  makes  writing  a 
debugging  tool  like  this  a  little  harder.  To  do  so  you  need  to  edit  the 
headers  so  they  compile  in  your  project  through  a  process  I  call 
“munging.” 

Sesek’ s  method  was  modified  to  access  the  kernel  definitions  needed  for  offsets. c 
using  the  following  steps  applied  to  each  required  header: 

1 .  Identify  all  required  definitions  in  a  given  header  file,  cut  the  file  content  after  the 
last  statement  needed  to  avoid  irrelevant  dependencies. 

2.  Remove  any  #ifdef  macros  necessary  to  expose  the  target  definitions. 

3.  Remove  any  # include  statements  for  kernel  dependencies  and  replace  with  a 
local  version  of  each  header  file  containing  a  required  definition. 

4.  Recursively  apply  steps  1-4  for  each  local  header  added. 

5.  Troubleshoot  ad  nauseam  until  the  target  header  can  be  included  without 
compilation  error. 

These  steps  must  be  completed  for  each  supported  version  of  OS  X  due  to  subtle  changes 
within  the  header  files.  For  the  10.7  version  of  the  offsets  program  27  different  header 
files  were  required  to  define  the  data  structures  needed  by  the  open  files  module.  The 
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10.6  version  uses  only  17  headers  beeause  many  of  the  required  definitions  are  relocated 
to  the  dependent  file  rather  than  including  them  recursively. 

Three  out  of  18  template  functions  written  for  offsets. c  are  known  to  produce 
incorrect  member  offsets  for  64-bit  kernel  architecture.  The  problem  is  believed  to  be  a 
complex  definition  conflict  for  some  low-level  types.  Several  C  types  are  defined  for 
userspace  with  standard  libraries  such  as  stdio  .  h.  However,  the  kernel  sometime  uses 
different  sizes  for  these  same  types  and  forced  redefinition  yields  a  compilation  error. 
When  the  offsetof  macro  measures  a  userspace  definition  the  result  is  an  error  for 
some  architectures.  Figure  18  shows  the  offsets. c  template  contradicting  the  value 
calculated  manually  from  the  structure  definition  in  Figure  19. 


struct_ubcinf o  =  { ' ui_size ' : ( ' of f_t ',32,8, ' SIZE /OFF ' ) } 


Figure  18.  10.7  x64  template  for  struct  ubc_inf o. 


struct  ubc_info  { 

memory_ob j ect_t  ui_pager; 

memory_ob j ect_control_t  ui_control ; 
uint32_t  ui_flags; 


vnode_t 
kauth  cred  t 


ui_vnode ; 
ui  ucred; 


//  8-byte  pointer 
//  8-byte  pointer 
//  4-byte  int 

//  4-byte  PAD  (ptr  alignment) 
//  8  byte  pointer 
//  8  byte  pointer 
//  - 

//  40-byte  offset 


off  t 


u  i  s  i  z  e  ; 


//  8-byte  int 


Figure  19.  Manual  offset  calculation  for  64-bit  struct  ubc_inf o  (annotated). 
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Table  6.  Manual  hex  sizing. 


ubc_info 

uLpager 

uLcontrol 

hex 

A03F4207 

80FFFFFF 

C02B3B07 

80FFFFFF 

human 

ffffff 8007423fa0 

ffffff 80073b2bc0 

1  n 

ubc_info 

ui_flags 

ui_vnode 

hex 

IFOOOOOO 

00000000 

00104007 

80FFFFFF 

human 

31 

ffffff 8007401000 

1  n 

ubc_info 

ui_ucred 

ui_size 

hex 

00000000 

00000000 

00EE1400 

00000000 

human 

NULL 

1371648 

The  printhex  ( )  utility  written  for  the  open  files  module  ean  be  used  to  print 
the  address  spaee  in  hex  of  a  problematie  strueture  for  debugging.  Output  ean  be  used  to 
eonfirm  manual  sizing  as  shown  in  Table  6.  The  correet  value  of  ui_size  in  the 
example  ean  be  verified  using  output  from  the  UNIX  Isof  eommand  on  the  maehine  the 
memory  was  eaptured  from  to  be  sure  the  interpretation  is  eorreet.  This  analysis  indieates 
ui_size  should  have  a  40-byte  offset  instead  of  36  in  the  template  for  struct 
ubc_info.  Similar  offset  issues  exist  in  the  off  set.  c  templates  for  struct 
vnode_pager  and  struct  task.  Manual  offset  ealeulation  and  hex  analysis  was 
effective  in  resolving  the  problem  for  these  templates  as  well.  In  all  three  cases,  the 
solution  is  a  manual  adjustment  made  to  the  TEMPLATES  constant  of  the  equivalent 
structure  class  in  Isof  .  py. 

A  wrapper  for  offsets  .  c  called  printstructs  .py  is  written  to  verify  the 
output  dictionary  as  executable  Python  code  and  also  print  the  structure  members  in  a 
human-readable  format  for  ease  of  debugging.  Figure  20  shows  the  output  of  the 
program.  The  architecture  argument  on  the  command  line  instructs  printstructs.py 
to  compile  offsets  .  c  using  gcc  -arch  with  either  138  6  or  x8  6_64  specified  as 
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$  . /printstructsG . py  64  -p 

struct_proc  =  { ' p_list ' : ( ' LIST_ENTRY (proc)',0,16,'',{' le_next ' : (  [ . . . ] 

-  struct  proc  (6x64)  - 

LIST_ENTRY (proc)  p_list  0  16 

struct  proc  *le_next  0  8 

struct  proc  **le_prev  8  8 


pid  t  p  pid 

16 

4 

PID 

void  *task 

24 

8 

struct  filedesc 

*p  f d 

200 

8 

struct  vnode  *p 

textvp 

664 

8 

char [ ]  p  comm 

700 

17 

COMMAND 

struct  pgrp  *p 

pgrp 

752 

8 

Figure  20.  Template  output  from  print  struct  s  .py. 


appropriate.  The  -arch  flag  is  an  Apple-only  option  aceording  to  the  gcc  manpage, 
though  in  limited  testing  the  standard  -m3  2  and  -m64  flags  also  appear  to  work.  Setting 
the  flag  allows  one  version  of  offset. c  to  produee  templates  for  both  the  32  and  64-bit 
installations.  Dictionary  output  from  printstructs.py  was  then  pasted  into  the 
TEMPLATES  constant  of  each  class  in  Isof  .  py  to  complete  the  definition. 

3.4.4  Unions  and  Type  Ambiguity. 

As  discussed  in  Section  3.2.1,  the  union  data  structure  and  generic  pointers  can 
lead  to  ambiguity  which  must  be  well-handled  by  the  open  files  module.  One  example  is 
the  vm_object  member  of  struct  vm_map_entry.  This  union  may  refer  to  a 
pointer  for  vm_ob  j  ect  or  _vm_map  and  the  address  itself  cannot  be  used  to  distinguish 
the  two.  The  open  fdes  module  deals  with  this  situation  by  implementing  a  template  test, 
which  unpacks  the  values  at  certain  offsets  and  attempts  to  match  these  with  the  types 
expected  for  the  template  of  a  particular  structure.  The  initializer  for  class 
Vm_ob  j  ect  demonstrates  the  technique  in  Figure  21. 
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The  vm_ob  j  ect  object  structure  is  characterized  by  two  pointer  members  followed  by  a 
lock,  which  is  in  contrast  to  the  lock  followed  by  two  pointers  in  the  _vm_map 
definition.  Moreover,  vm_ob  j  ect  appears  to  initialize  these  pointers  with  the  address  of 
the  object  itself,  suggesting  both  should  always  be  valid  when  tested.  The  template  test 
provides  a  reliable  indicator  of  the  structure  type  for  the  pointer  stored  at 
vm_ob  j  ect .  vm_map_entry  and  is  used  to  branch  program  logic. 


class  Vin_object  (Struct)  : 

TEMPLATES  =  (...) 

def  _ init _ (self,  addr) : 

super  (Vin_object,  self)  . _ init _ (addr) 

self. map  =  None 

ptrl  =  unpacktype ( self . smem,  self . template [' memq '][ 4 ][' next '] ,  INT) 
ptr2  =  unpacktype ( self . smem,  self . template [' memq '][ 4 ][' prev '] ,  INT) 

if  ptrl  ==  0  or  ptr2  ==  0  \ 

or  not ( Struct . mem . is_valid_address (ptrl ) )  \ 

or  not (Struct. mem . is_valid_address (ptr2 ) ) : 

#  on  failure,  create  map  instance  to  be  called  recursively 
self. map  =  Vm map(addr) 

Figure  21.  Template  testing. 


3.4.5 Modifications  to  volafox.py. 

The  implementation  for  listing  open  files  is  confined  to  the  source  file  Isof  .py 
whenever  possible  in  order  to  support  modular  software  design.  However,  three 
noteworthy  changes  are  required  to  integrate  new  code  with  the  existing  volafox.py 
source  file.  First,  additional  argument  handling  is  needed  to  direct  execution  of  the  open 
files  module  from  the  command  line.  The  modified  volafox  usage  statement  in  Figure  22 
explains  the  new  options. 
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$  python  volafox.py 


volafox:  release  r52;  Isof  research  build  1.0 
project:  http: / /code . google . com/p /volafox 
Isof:  osxmein@gmail.com 
support:  10.6-7;  32/64-bit  kernel 

input:  *.vmem,  *.mmr  (Mac  Memory  Reader,  flattened  x86) 
usage:  python  volafox.py  -1  IMAGE  [-o  COMMAND  [-vp  PID] ] 

[-m  KEXT_ID] [-x  PID] 

WARNING:  this  is  an  experimental  development  build  adding  support  for 
listing  open  files.  The  code  here  is  NOT  in  sync  with  project  trunk. 


Options 
-o  CMD 

-p  PID 

-V 

-m  KID 
-X  PID 


Print  kernel  information  for  CMD  (below) 

List  open  files  for  PID  (where  CMD  is  "Isof") 

Include  unsupported  types  in  listing  (where  CMD  is  "Isof") 

Dump  kernel  extension  address  space  for  KID 
Dump  process  address  space  for  PID 


COMMANDS : 


os_version 
machine_inf o 
mount_inf o 
kern_kext_inf o 
kext_inf o 
proc_inf o 
syscall_inf o 
net_inf o 
Isof 


Mac  OS  X  build  version 

kernel  version,  CPU,  and  memory  specifications 
mounted  filesystems 

kernel  KEXT  (Kernel  Extensions)  listing 
KEXT  (Kernel  Extensions)  listing 
process  list 
syscall  table 

network  socket  listing  (hash  table) 

open  files  listing  by  process  (research) 


Figure  22.  volafox  usage  statement. 


The  optional  -p  flag  emulates  the  UNIX  Isof  eommand  option  to  print  open  files  only 
for  a  speeified  proeess.  Beeause  the  new  module  only  fully  supports  the  handle  types 
deseribed  in  Seetion  3.1.3,  the  -v  flag  was  added  to  avoid  output  of  limited  value  to  the 
examiner  by  default.  The  eode  supporting  the  new  options  is  of  generie,  imperative 
design  is  therefore  not  discussed  in  detail. 
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Figure  23  shows  the  second  modification,  a  new  module  branch  added  to  main  ( ) ,  note 


the  call  to  printf  ilelist  ( ) ,  one  of  two  public  functions  in  Isof  .  py. 


elif  oflag  ==  'Isof': 

filelist  =  m_volaf ox . Isof ( symbol_list [ ' _kernproc ' ] ,  pid,  vflag) 
if  vflag: 
print  "" 

printf ilelist (filelist) 
sys . exit ( ) 

Figure  23.  volafox  Isof  command  branch. 


Finally,  Figure  24  shows  the  stub  method  added  to  class  volafox  which  calls  the 
second  public  function  getfilelistO. 


def  Isof  (self,  sym_addr,  pid,  vflag): 

if  self. arch  ==  32: 

overlay  starting  at  symbol  _kernproc 
kernproc  =  self . x86_mem_pae . read (sym_addr,  4); 

proc_head  =  struct . unpack (' I ' ,  kernproc) [0] 

else:  #  64-bit 

kernproc  =  self . x86_mem_pae . read (sym_addr,  8); 
proc_head  =  struct . unpack (' Q ' ,  kernproc) [0] 

return  getf ilelist ( self . x8 6_mem_pae ,  self. arch,  self . os_version,  \ 

proc head,  pid,  vflag) 

Figure  24.  Isof  method  stub  added  to  class  volafox. 
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3,5  Open  Issues 

While  the  majority  of  system  design  goals  outlined  for  the  open  files  module  in 
Section  3.1  are  met  by  the  implementation  described  in  3.4,  there  are  two  outstanding 
deficiencies  not  accounted  for  in  the  constraints  specified.  Both  describe  limitations  of 
the  kernel  structure  analysis  rather  than  programming  error.  Problems  reporting  the 
correct  process  user  and  sizing  the  /dev  directory  are  discussed  in  this  section. 

3.5.1  User  Field  Reporting. 

The  manpage  for  the  UNIX  Isof  command  describes  the  output  of  the  USER 
field  as  “the  user  ID  number  or  login  name  of  the  user  to  whom  the  process  belongs, 
usually  the  same  as  reported  by  ps  (1)  ”.  However,  output  from  the  volafox  open  fdes 


module  is  known  to  incorrectly  report  the  process  login  name  as  shown  in  Figures  25-26. 


$  ./volafox.py 

-i  10. 

6.8x86. 

,  vmem  -o 

Isof  -p  15 

COMMAND 

PID 

USER 

ED 

TYPE 

DEVICE 

SIZE/OFF  NODE 

distnoted 

15 

root 

cwd 

DIR 

14,2 

1088  2 

distnoted 

15 

root 

txt 

REG 

14,2 

50672  268317 

distnoted 

15 

root 

txt 

REG 

14,2 

1054960  264388 

distnoted 

15 

root 

txt 

REG 

14,2 

213385216  466405 

distnoted 

15 

root 

Or 

CHR 

3,2 

OtO  297 

distnoted 

15 

root 

1 

PIPE 

-1 

-1  -1 

distnoted 

15 

root 

2 

PIPE 

-1 

-1  -1 

distnoted 

15 

root 

3u 

KQUEUE 

-1 

-1  -1 

distnoted 

15 

root 

56u 

SOCKET 

-1 

-1  -1 

Figure  25.  volafox  user  output. 


#  Isof  -p  15 


COMMAND 

PID 

USER 

ED 

TYPE 

DEVICE 

SIZE/OFF 

NODE  [... 

distnoted 

15 

daemon 

cwd 

DIR 

14,2 

1088 

2  [... 

distnoted 

15 

daemon 

txt 

REG 

14,2 

50672 

268317  [... 

distnoted 

15 

daemon 

txt 

REG 

14,2 

1054960 

264388  [... 

distnoted 

15 

daemon 

txt 

REG 

14,2 

213385216 

466405  [... 

distnoted 

15 

daemon 

Or 

CHR 

3,2 

OtO 

297  [... 

distnoted 

15 

daemon 

1 

PIPE 

0x02fe2af 8 

16384 

[... 

distnoted 

15 

daemon 

2 

PIPE 

0x02fe2af 8 

16384 

[... 

distnoted 

15 

daemon 

3u 

KQUEUE 

[... 

distnoted 

15 

daemon 

56u 

Unix 

0x02fdef 80 

OtO 

[... 

Figure  26.  Isof  user  output. 
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The  difference  shown  is  not  consistent  across  all  processes  of  a  full  file  listing.  In  many 
cases  the  expected  USER  value  is  reflected  in  the  output,  but  not  always. 

The  first  test  in  investigating  this  issue  is  to  determine  whether  the  problem  is 
specific  to  the  volafox  open  files  module  implementation.  Since  this  part  of  the  open  files 
methodology  is  taken  from  the  proc_info  command,  the  same  erroneous  output  for  a 
given  process  is  expected  from  both  commands.  Figure  27  shows  that  both  the  Isof  and 
proc_info  commands  agree  on  the  USER  ‘root’,  demonstrating  the  problem  is  not 
isolated  to  the  open  fdes  module. 


$  . /volafox. py  -i 

kD 

O 

I — 1 

,8x86.' 

vmem  -o  proc  info 

list  entry  next 

pid 

ppid 

process  name 

username 

02f74d20 

0 

0 

kernel  task 

02f747e0 

1 

0 

launchd 

Gad 

02f74540 

10 

1 

kextd 

root 

02f74000 

11 

1 

notif yd 

root 

03271d20 

12 

1 

diskarbitratlond 

root 

03271540 

15 

1 

distnoted 

root 

Figure  27.  volafox  proc_inf  o  output. 

The  second  test  confirms  correctness  of  the  volafox  proc_info  command 
implementation.  Volafox  parses  the  username  based  on  Suiche’s  original  analysis,  which 
states  a  “[pjointer  to  the  process  group,  pgrp  structure,  allows  us  to  retrieve  the 
username  of  the  person  who  launched  the  program  because  this  structure  contains  a 
pointer  to  a  structure  called  session  with  the  username”  (2010).  Figure  28,  a 
screenshot  from  his  conference  slides,  shows  the  username  nfi  for  the  launchd 
process.  Here  nfi  (short  for  Netherlands  Forensic  Institute)  is  a  local  user  and  therefore 
cannot  be  the  correct  username  for  the  launchd  process.  As  Singh  explains,  “user-level 
startup  is  initiated  when  the  kernel  executes  /sbin/ launchd  as  the  first  user  process” 
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taskll 

pid 

parent  pid  nane  usernane 

0 

0 

0  kernel  task 

1 

1 

0  launchd 

2 

10 

1  kextd 

3 

11 

1  notifyd 

4 

12 

1  syslogd 

5 

16 

1  update 

6 

19 

1  securityd 

7 

21 

1  nds 

8 

22 

1  nDNSResponder 

9 

23 

1  loginwindow 

10 

24 

1  KernelEuentAgent 

11 

26 

1  hidd 

12 

27 

1  fseuentsd 

13 

28 

1  dynanic_pager 

14 

31 

1  diskarbitrat iond 

15 

32 

1  DirectoryService 

16 

34 

1  conf igd 

17 

37 

1  autofsd 

18 

38 

1  socket! ilterf w 

19 

41 

1  distnoted 

20 

47 

1  coreservicesd 

21 

48 

1  UindowServer 

22 

65 

1  coreaudiod 

23 

69 

1  launchd 

24 

76 

69  Spotlight 

25 

77 

69  UserEwent Agent 

26 

79 

69  pboard 

27 

80 

69  Dock 

28 

81 

69  SystenUIServer 

29 

82 

69  Finder 

30 

83 

69  ATSServer 

31 

95 

69  Terninal 

32 

96 

95  ^»:5 

33 

97 

96  bash 

34 

158 

69  Xcode 

35 

853 

80  DashboardClient 

36 

1134 

69  Property  List  Ed 

37 

2578 

69  Safari 

38 

2588 

95  login 

39 

2589 

2588  bash 

40 

3714 

1  ntpd 

41 

3837 

1  ndworker 

42 

3898 

1  ndworker 

43 

3906 

69  AppleSpell 

44 

3908 

97  dd 

Figure  28.  Suiche  process  list  output  (2010). 


(2006b).  The  launchd  process  is  therefore  always  associated  with  the  username  root 
since  the  kernel  is  responsible  for  executing  it.  This  demonstrates  the  problem  is  also  not 
specific  to  the  volafox  implementation  of  Suiche’s  methodology. 


66 


The  third  test  determines  whether  the  diserepancy  could  be  the  result  of  a 
semantic  difference  between  the  user/username  fields  from  the  Suiche  analysis  and  the 
Isof  manpage.  The  manpage’s  “login  name  of  the  user  to  whom  the  process  belongs” 
could  contradict  Suiche’s  definition  of  a  user  as  “the  person  who  launched  the  program.” 
The  ps  command  offers  a  variety  of  keywords  associated  with  users  and  names  that  can 
help.  Figure  29  shows  the  ps  output  for  PID  15,  the  same  example  previously  shown. 

#  ps  -p  15  -o  ucomm, pid, logname, ruser , user 

UCOMM  PID  LOGIN  RUSER  USER 

distnoted  15  daemon  daemon  daemon 

Figure  29.  ps  name  keywords. 

This  result  rules  out  the  possibility  that  Suiche  was  discussing  a  different,  but 
nevertheless  related  and  valid  username.  Figure  30  is  the  same  output  for  launchd, 
showing  the  username  nf  i  for  PID  1  must  also  be  incorrect  for  all  user  keywords. 

#  ps  -p  1  -o  ucomm, pid, logname, ruser, user 
UCOMM  PID  LOGIN  RUSER  USER 

launchd  1  root  root  root 

Figure  30.  launchd  name  keywords. 

In  a  fourth  test,  output  of  the  ps  command  is  used  to  analyze  the  structures 
involved  with  username  output.  The  ps  manpage  states  the  keyword  logname  reports 
the  “login  name  of  user  who  started  the  session”  and  sess  is  the  “session  ID.”  Both 
keywords  are  likely  related  to  the  session  structure  Suiche  pulls  the  username  from. 
Figure  31  shows  the  output  of  both  for  the  ongoing  example. 
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#  ps  -p  15  -o  ucomm, pid, user, logname, sess 
UCOMM  PID  USER  LOGIN  SESS 

distnoted  15  daemon  daemon  2fd65f0 


Figure  31.  ps  session  keywords. 


The  hex  output  for  field  “session  ID”  is  equivalent  to  50161136  in  decimal,  so  the  value 
appears  to  be  a  pointer  rather  than  an  integer  as  one  might  expect  from  the  ps  definition. 
The  simple  modification  in  Figure  32  to  the  class  Session  initializer  allows  volafox 
to  print  this  address  for  comparison  as  shown  in  the  output  Figure  33. 


class  Session  (Struct)  : 

TEMPLATES  =  { . . . } 

def  _ init _ (self,  addr) : 

super  (Session,  self)  . _ init _ (addr) 

print  "Session  Address:  %x"  %addr 


Figure  32.  class  Session  testing  modification. 


$  python  volafox. py  -i  10 . 6 . 8x86 . vmem  -o  Isof  -p  15 
Session  address:  2fd65f0 

COMMAND  PID  USER  ED  TYPE  DEVICE  SIZE/OFF  NODE  NAME 

distnoted  15  root  cwd  DIR  14,2  1088  2  /dev/null 


Figure  33.  struct  session  address. 


Because  the  ps  keyword  sess  and  volafox  both  report  the  same  address  for  struct 
session,  there  is  evidence  to  suggest  the  session. s_login  [MAXLOGNAME ] 
member  interrogated  by  volafox  is  correct  for  the  keyword  logname.  The  discrepancy 
therefore  does  not  appear  to  be  a  fault  in  the  source  analysis  by  Suiche. 
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The  final  test  in  this  investigation  determines  if  the  intermittent  diserepaney  ean 
be  explained  by  changes  to  the  structure  linked-lists  during  memory  capture.  Hay  and 
Nance  (2009)  discuss  problems  associated  with  inconsistent  memory  snapshots  resulting 
from  state  changes  during  capture.  The  goal  is  to  show  that  the  pgrp  and  session 
structures  that  are  returned  for  these  failure  cases  are  in  fact  correct  for  the  process,  and 
not  in  some  momentary  transitional  state  recorded  in  the  image.  To  accomplish  this, 
volafox  is  modified  to  print  the  values  of  additional  struct  members  not  required  for  the 
open  files  module  implementation.  The  results  of  these  experiments  have  shown: 

1.  In  all  cases  observed,  proc.p_pid  ==  proc.p_pgpid,  meaning  the 
process  group  identifier  can  be  used  as  a  reference  to  a  process.  Note  that  as 
verified  in  ps,  the  keyword  gid  pgid.  The  process  group  identifier  references 
a  specific  process  within  a  group,  it  does  not  identify  the  group  itself 

2.  For  all  failure  cases  proc.p_pgrpid  ==  pgrp.pg_id  ==  session.  s_id. 
Since  all  three  structures  store  a  correct  identifier  referencing  the  source  process, 
a  reference  error  does  not  appear  to  be  at  fault. 

3.  The  session .  s_leader  member  is  a  proc  structure  pointer  described  in  the 
comments  as  “Session  leader,  (static)”.  In  all  failure  cases,  this  points  back  the 
source  process  so  there  is  no  reference  error  apparent  from  either  direction. 

4.  The  proc.  si_uid  member  is  the  only  example  in  any  of  the  three  structures 
discussed  that  is  typed  uid_t  (user  identifier).  However,  it  does  not  correctly 
identify  the  process  UID  output  of  ps.  Therefore,  supplying  the  UID  rather  than 
username  does  not  appear  to  be  a  valid  alternative. 


Despite  the  previous  analysis,  neither  the  source  nor  the  solution  to  the  username 
field-reporting  error  is  identified.  There  is  also  no  known  method  to  determine  when  the 
session  structure  returns  the  correct  value.  The  bug  derives  from  prior  work  that  is  not 
the  direct  focus  of  the  research  and  therefore  is  not  explored  further. 
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3.5.2  Sizing  the  /dev  Directory. 

A  second  problem  identified  during  development  is  an  inability  to  correctly  report 
the  SIZE/OFF  field  for  certain  directories.  The  /dev  directory  is  typed  DTYPE_VNODE 
in  f  ileglob .  f  g_type  and  VDIR  in  vnode .  v_type.  However,  it  has  a  tag  of 
VT_DEVES  from  vnode. v_tag  rather  than  the  VT_HES  seen  for  most  other 
directories.  Figure  34  shows  an  example  of  /dev  as  reported  by  the  FTNIX  Isof 
command. 

#  Isof  +d  /dev 

COMMAND  PID  USER  ED  TYPE  DEVICE  SIZE/OFF  NODE  NAME 

launchd  1  root  8r  DIR  20,5853800  4495  305  /dev 

Figure  34.  /dev  directory  size. 

Note  that  4495  mod  34  A  0,  and  therefore  sizing  by  the  entry  count  as 
described  in  Section  3.2  is  not  valid  for  this  directory.  Table  4  gives  three  alternate 
locations  for  the  size  applicable  to  other  file  types,  but  none  were  found  to  be  effective  in 
this  case.  Fortunately,  due  to  the  unique  combination  of  tag  and  type  for  /dev,  the 
failure  is  possible  to  detect.  Since  the  location  of  the  size  is  unknown,  the  volafox  open 
files  module  prints  -1  for  the  size  of  /dev  to  indicate  the  field  is  unsupported. 
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3,6  Summary 

Section  3.1  of  this  chapter  introduces  the  goals  for  a  new  volafox  module  to  list 
open  files  from  a  raw  memory  dump.  Section  3.2  covers  design  recovery  of  the  kernel 
structures  responsible  for  the  process  file  descriptor  table  and  memory-mapped  files. 
Section  3.3  reviews  technical  details  for  the  existing  volafox  source  code.  Section  3.4 
describes  the  open  fdes  module  implementation,  including  the  new  source  file  Isof  .py 
and  external  programs  off  sets,  c  and  printstructs .  py.  Finally,  Section  3.5 
offers  an  analysis  of  open  issues  related  to  the  implementation. 

Significant  effort  is  put  forth  to  ensure  a  well-engineered  solution  which  adheres 
to  fundamental  software  design  principles.  The  result  is  a  modular,  object-oriented 
implementation  with  a  minimal  interface  to  the  existing  volafox  source.  For  comparison, 
the  analogous  volafox  output  for  the  information  printed  by  the  UNIX  Isof  command  in 
Figure  3  concludes  this  chapter  as  Figure  35. 


$  . /volafox . py 

•  -1 

kD 

O 

I — 1 

8x8G.vmem  -o 

Isof  -p  109 

COMMAND 

PID 

USER 

ED 

TYPE 

DEVICE 

SIZE/OFF  NODE 

NAME 

bash 

109 

Gad 

cwd 

DIR 

14,2 

578  202041 

/Users/Gad 

bash 

109 

Gad 

txt 

REG 

14,2 

134G544  2G2558 

/bln/bash 

bash 

109 

Gad 

txt 

REG 

14,2 

10549G0  2G4388 

/usr/llb/dyld 

bash 

109 

Gad 

txt 

REG 

14,2 

21338521G  4GG405 

/private/var /db/ 
dyld/dyld  shared 
cache  x8G  G4 

bash 

109 

Gad 

Ou 

CHR 

IG,  0 

0t400  Gll 

/dev/ttysOOO 

bash 

109 

Gad 

lu 

CHR 

IG,  0 

0t400  Gll 

/dev/ttysOOO 

bash 

109 

Gad 

2u 

CHR 

IG,  0 

0t400  Gll 

/dev/ttysOOO 

bash 

109 

Gad 

255u 

CHR 

IG,  0 

0t400  Gll 

/dev/ttysOOO 

Figure  35.  volafox  open  files  listing. 
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IV.  Results  and  Analysis 


This  chapter  tests  the  effeetiveness  of  the  volafox  module  implemented  for  listing 
open  files  from  an  OS  X  memory  eapture.  As  discussed  in  Section  3.1.2,  one  reason  for 
selecting  the  UNIX  Isof  (list  open  files)  command  as  the  output  format  model  for  the 
volafox  handles  module  is  the  relative  ease  with  which  it  can  be  validated.  When 
exeeuted  with  administrator  privileges  on  a  test  system,  output  provided  by  Isof  aets  as 
a  baseline  against  whieh  analysis  on  memory  captured  from  the  same  system  can  be 
measured. 

The  following  seetions  define  a  suceessful  researeh  outeome  and  deseribe  the 
tools,  processes,  and  definitions  used  to  analyze  the  implementation.  A  suite  of  software 
test  cases  consisting  of  two  OS  X  versions  running  both  32  and  64-bit  kernel  arehitecture 
is  used  to  validate  the  tool.  Finally,  physical  memory  captured  on  a  variety  of  Mac 
models  is  used  to  exercise  the  tool  on  real-world  data. 

4,1  Module  Evaluation  Methodology 

A  successful  implementation  of  the  volafox  open  files  module  must  aecurately 
report  all  file  handles,  adjusted  for  stated  eonstraints  and  known  deficiencies.  However, 
because  the  module  represents  novel  researeh,  no  tool  exists  to  validate  the  output  using 
only  the  image  of  physical  memory.  Therefore,  validation  must  compare  data  that 
approximates  the  state  of  open  files  when  the  collection  occurred.  The  UNIX  Isof 
eommand  offers  a  source  of  data  for  comparison  when  output  is  redirected  to  a  file  just 
before  suspending  a  VM  or  exeeuting  the  Mac  Memory  Reader  eapture  tool. 
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Given  the  difficulty  of  direct  validation,  success  must  be  redefined  in  terms  of  the 
degree  to  which  the  volafox  output  matches  that  of  the  UNIX  Isof  command.  The 
complex  nature  of  a  modem  operating  system  like  OS  X  guarantees  changes  to  the 
system  state  between  the  time  when  the  Isof  command  is  mn  and  the  memory  dump 
occurs  (Hay  &  Nance,  2009).  Some  allowance  is  necessary  to  account  for  changes  during 
this  interval.  A  successful  implementation  therefore  becomes  one  that  can  be  validated 
against  the  UNIX  Isof  command,  adjusted  for  stated  constraints,  known  deficiencies, 
and  accuracy  of  the  validation  method. 

By  this  definition,  limitations  of  the  program  that  are  also  shared  by  Isof  are 
not  an  indication  of  correctness.  For  example,  while  the  HFS+  filesystem  supports  16-bit 
Unicode  file  names,  Isof  “only  outputs  printable  [...]  8  bit  characters”  per  its  manpage. 
Therefore,  the  lack  of  Unicode  support  within  the  volafox  open  files  module  is  not 
considered  a  shortcoming  of  the  implementation  for  the  purpose  of  this  research  analysis. 

4.1.1  Test  Configuration  and  Design. 

The  following  sections  provide  a  step-by-step  description  of  the  processes  used  to 
configure,  collect,  and  compare  the  results  discussed  in  Section  4.2  and  employ  the 
research  tools  capture.py  and  validate  .  py  developed  for  analysis. 

4. 1.1.1  Controlled  Test  Configuration. 

This  section  describes  the  process  for  configuring  OS  X  virtual  machines  used  to 
validate  the  research  implementation.  Output  of  the  process  is  a  virtual  machine  prepared 
for  the  data  collection  process.  The  resulting  configuration  is  intended  to  minimize 
operating  system  activity  during  the  time  between  when  the  validation  data  is  gathered 
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and  the  memory  image  is  ereated.  This  is  done  so  that  analysis  may  focus  on  differences 
caused  by  the  implementation,  rather  than  those  resulting  from  temporal  changes  that 
occur  during  normal  operating  conditions.  Graphical  navigation  paths  begin  with 
references  to  items  in  the  OS  X  menu  bar. 

1 .  Install  guest  using  the  VMware  Fusion  Virtual  Machine  Assistant  with  default 
settings  for  the  OS  X  version  being  configured.  Wizard  will  select  minimum 
RAM  configuration  for  that  version.  Note:  Apple  specifies  2  GB  of  RAM  in  the 
system  requirements  for  10.6  Server,  however  VMware  selects  1  GB  which 
installed  and  tested  without  issue  during  this  research. 

2.  Install  guest  updates  (10.6.8  and  10.7.3  test  cases  only):  il  Software  Update 

3.  Disable  optional  virtual  hardware  and  host  interaction  in  VMware  Fusion. 

a.  Do  not  install  the  VMware  Tools  daemon. 

b.  Virtual  Machine  ^  Settings  USB  &  Bluetooth  ^  uncheck  all 

c.  Virtual  Machine  Settings  Sound  Card  Sound  Card;  OFF 

d.  Virtual  Machine  Settings  CD/DVD  Enable  CD/DVD  Drive;  OFF 

e.  Virtual  Machine  Settings  Display  Accelerate  3D  Graphics;  OFF 

f  Virtual  Machine  Settings  Sharing  Shared  Folders;  OFF 

4.  Disable  networking. 

a.  Guest;  il  System  Preferences  Network;  remove  all  interfaces 

b.  VMware  Fusion;  Virtual  Machine  Settings  Network  Adaptor  Enable 
Network  Adaptor;  OFF 

5.  Remove  OS  X  startup  items  in  the  guest. 

a.  Select  and  delete  any  items  in  the  following  directories; 

~/ Library/ LaunchAgents 
/Library/LaunchAgents 
/Library/LaunchDaemons 
/Library/ Startupitems 

b.  il  System  Preferences  Users  &  Groups  Login  Items;  remove  all 
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6.  Disable  other  daemons  in  the  guest. 

a.  il  System  Preferenees  Software  Update  Cheek  for  updates:  uncheck 

b.  il  ^  System  Preferenees  Date  &  Time  Set  date  and  time  automatieally: 

unckeck 

e.  il  System  Preferenees  ^  Desktop  &  Sereen  Saver  ^  Start  sereen  saver: 
never 

d.  il  System  Preferenees  Energy  Saver  Computer  sleep:  never.  Display 

sleep:  never,  uncheck  all  other  options 

e.  Spotlight  indexing,  Terminal. app: 

#  mdutil  -a  -i  off 

f  Server  administrative  daemon  (10.6  Server  test  ease  only).  Terminal. app: 

#  cd  /System/Library/LaunchDaemons/ 

#  launchctl  unload  -w  com. apple . servermgrd.plist 

4. 1.1. 2  Controlled  Data  Collection. 

This  seetion  deseribes  the  proeess  for  eolleeting  validation  data  and  an  image  of 
physieal  memory  from  virtual  maehines  eonfigured  to  test  the  tool.  The  proeess  outputs  a 
text  file  eontaining  the  handles  reported  by  the  Isof  eommand,  and  an  image  of  physieal 
memory  saved  by  VMware  Fusion  when  the  virtual  maehine  is  suspended  (Seetion 
2.4.1).  All  steps  referenee  aetions  in  the  guest  OS  unless  stated  otherwise. 

1.  Launeh  Terminal. app  from  /  Applications /Utilities.  Perform  an 
exeeution  of  isof  with  administrator  privileges  prior  to  data  eolleetion.  The 
isof  manpage  indieates  eertain  data  struetures  may  be  eaehed  so  this  ensures 
minimum  filesystem  interaetion  when  the  eommand  is  run  for  data  eolleetion. 

2.  Let  the  system  stabilize  with  no  user  interaetion  for  approximately  5  minutes. 

3.  Colleet  validation  data,  from  Terminal. app: 

#  isof  >  ~/lsof.out 
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4.  Once  command-prompt  reappears,  user  immediately  navigates  to  and  clieks  the 
suspend  button  in  the  upper-left-hand  corner  of  the  virtual  maehine  window. 

5.  Host:  eopy  suspended  memory  image,  from  Terminal. app: 

$  cp  PATH /TEST_C AS E .vmwarevm/ * .vmem  -/Desktop 

6.  Resume  virtual  machine  and  reeover  the  Isof  .  out  validation  data  file.  Because 
networking  and  sharing  are  disabled,  USB  support  is  enabled  in  the  guest  so  the 
file  can  be  eopied  to  the  host  via  external  media. 

4. 1.1. 3  Real-word  Data  Collection. 

This  section  describes  the  proeess  used  to  eolleet  real-world  data  from  Mao 
oomputers.  The  process  outputs  a  text  file  oontaining  the  handles  reported  by  the  Isof 
command,  and  an  image  of  physical  memory  originally  created  by  the  Mac  Memory 
Reader  tool,  which  is  then  converted  using  the  volafox  utility  described  in  Seotion  3.3.1. 

1 .  Create  a  colleotion  toolkit  using  a  forensic  workstation.  First  format  external  USB 
media  as  HFS+  in  the  OS  X  Disk  Utility  applioation.  Next,  eopy  the  soript 
capture  .  py  (Section  4.2.4)  and  a  directory  containing  Mac  Memory  Reader 
kernel  extension  along  with  its  dependencies  to  the  root  of  the  formatted  deviee. 

2.  Plug  toolkit  into  the  Mac  targeted  for  eollection. 

3.  Double-click  the  USB  deviee;  this  should  appear  on  the  desktop  onee  mounted. 
Within  the  resulting  window,  double-click  the  icon  named  capture  (the  OS  X 
Finder  dies  not  by  default  show  any  file  extension). 

4.  A  Terminal  window  will  launeh  and  prompt  the  user  for  an  administrator 
password.  Enter  the  password  and  follow  the  remaining  instructions.  The  seript 
will  report  the  total  time  elapsed  during  collection  when  execution  has  finished.  A 
new,  uniquely  named  directory  is  created  on  the  USB  toolkit  oontaining  both  the 
image  of  physical  memory  and  the  output  from  Isof  for  oomparison. 

5.  Drag  the  USB  toolkit  shown  on  the  desktop  to  the  trash  to  dismount,  then  unplug 
the  device. 

6.  Prior  to  analysis,  the  Mac  Memory  Reader  image  must  first  be  converted  to  a 
linear  format  compatible  with  volafox.  On  a  forensic  workstation,  execute  the 
following  from  the  volafox  source  eode  directory: 

$  python  f fatten. py  SOURCE. mmr  BEST. flat 
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4. 1.1. 4  Results  Comparison. 

The  tool  validate  .py  is  developed  to  eompare  output  of  the  Isof  command 
with  the  volafox  open  files  listing  using  Python’s  extensive  library  of  list  and  string 
operations.  The  result  is  a  custom  dif  f  program  used  to  build  the  tables  throughout  this 
chapter  and  its  related  appendices.  This  section  describes  both  the  process  for  using  the 
tool,  and  also  the  tool’s  processes  for  performing  comparison.  Two  input  files  are 
required  for  the  results  comparison  process.  First,  the  baseline  file  referred  to  here  as 
Isof  .out  contains  an  approximate  list  of  open  files  from  the  time  the  memory  was 
collected.  Second,  a  linear  memory  image  referred  to  here  as  image  .  mem  which  can  be 
analyzed  by  volafox.  Output  of  the  process  depends  on  the  source  data.  For  controlled 
test  cases,  applicable  results  are  analyzed  from  the  tables  in  Section  4.2.3  and  used  to 
validate  the  tool.  Results  for  real-world  test  cases  are  summarized  in  the  tables  of  Section 
4.2.4.  However,  these  are  not  considered  part  of  the  validation  methodology. 

1 .  Obtain  a  list  of  open  files  from  image  .  mem  using  volafox,  and  redirect  output  to 

file.  Include  -v  switch  to  print  all  handles  including  those  with  partial  support. 

$  python  voiafox  -i  image. mem  -vo  isof  >  vifx.out 

2.  Input  files  vif  x  .  out  and  isof  .  out  are  both  needed  to  run  vaiidate  .  py. 

The  script  compares  input  using  a  difference  taxonomy  (Section  4.1.2).  The  -s 

switch  is  used  when  analyzing  10.7  test  cases  (El).  Execute  the  following: 

$  python  vaiidate. py  [-s]  isof. out  vifx.out 

The  vaiidate  .  py  script  automates  the  following  sequence  of  steps: 

a.  Read  both  files  from  disk,  discard  the  header  line,  and  store  the  remaining 
lines  in  a  2D  array  split  on  whitespace.  The  resulting  matrices  use  a  row  for 
each  handle  and  a  column  for  each  isof  field  described  in  Table  3. 

b.  Adjust  the  list  of  processes  in  the  isof  matrix  for  El  and  E3  and  the  list  of 
handles  in  the  isof  matrix  for  E4. 
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c.  Adjust  the  process  list  in  the  volafox  matrix  for  E2  and  E3. 

d.  Align  the  list  of  processes  in  both  matrices  and  report  any  differences  as  E2. 

e.  Detect  differences  in  the  Isof  COMMAND  and  USER  fields  (columns  0  and 
2  of  the  matrix),  report  as  El  and  D1  respectively. 

f  Align  the  list  of  handles  (matrix  rows)  and  report  any  differences  as  E3. 

g.  Detect  differences  in  the  optional  file-mode  descriptor  from  the  Isof  ED 
field  (column  3)  and  report  any  differences  as  E4. 

h.  Detect  differences  in  the  Isof  TYPE  field  (column  4)  and  report  differences 
as  E5.  Do  not  consider  socket  (Cl)  or  symbolic  link  (E5)  handles. 

i.  Detect  differences  in  the  Isof  DEVICE  field  (column  5)  and  report 
differences  as  E6.  Do  not  consider  EIEO  (E6),  non-vnode  (C2),  or  non- 
HES+/DEVES  (C3)  handles. 

j.  Detect  differences  in  the  Isof  SIZE/OEE  field  (column  6)  and  report 
differences  as  E7.  Do  not  consider  non-vnode  (C2)  or  non-HES+/DEVES  (C3) 
handles,  nor  those  corresponding  to  the  /dev  directory  (D2)  or  the  ttys  file 
used  by  Isof  (E7). 

k.  Detect  differences  in  the  Isof  NODE  field  (column  7)  and  report  differences 
as  E8.  Do  not  consider  non- vnode  (C2)  or  non-HES+/DEVES  (C3)  handles. 

l.  Detect  differences  in  the  Isof  NAME  field  (column  8)  and  report  differences 
as  E8.  Do  not  consider  non-vnode  (C2)  handles. 

3.  Print  the  count  of  processes  or  handles  affected  by  the  constraints  (Cl -3), 
deficiencies  (Dl,2),  explained  differences  (El -7),  and  failures  (El -9)  described  in 
Section  4.1.2  to  STDOUT.  These  text  results  are  transcribed  into  the  detailed  test 
case  results  (Tables  15-28)  located  in  Appendix  E. 

4.  Ranges  of  real-world  test  case  results  are  summarized  in  Tables  12  and  13  for 
auxiliary  research  analysis.  However,  these  results  are  not  considered  part  of  the 
implementation  validation  methodology  described  in  the  following  steps. 

5.  Controlled  test  cases  results  are  examined  with  the  goal  of  identifying  previously 
unidentified  implementation  problems.  The  majority  of  constraints,  deficiencies, 
and  explained  differences  are  not  considered  in  this  analysis  as  the  failures  alone 
describe  possible  unknown  faults  in  the  tool  developed.  A  summary  of  these 
results  is  found  in  Tables  8-11.  Note  that  the  username  reporting  deficiency  (Dl) 
is  listed  only  to  emphasize  the  number  of  handles  affected  since  it  is  already 
classified  as  a  known  bug. 
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6.  Each  failure  reported  for  the  eontrolled  test  eases  is  analyzed  manually  to 
determine  if  it  is  likely  to  represent  a  validation  accuracy  fault,  or  an  unknown 
implementation  problem.  This  judgment  is  based  on  knowledge  of  OS  X  internals 
and  the  consistency  of  the  failure  across  test  cases. 

7.  The  differenee  taxonomy  deseribed  in  Seetion  4. 1 .2  is  developed  through  the 
iterative  application  of  this  process.  Reclassify  failures  as  defieieneies,  eonstraints 
or  explained  differenees  when  possible  and  repeat. 

4.1.2  Analysis  Taxonomy. 

This  seetion  identifies  differenees  between  the  Isof  eommand  and  output  from 
the  volafox  open  files  module  as  reported  by  validate. py.  Relationships  between 
elassifieations  are  diseussed  in  Seetion  4. 1.2. 4.  Order  listed  does  not  eorrespond  to  the 
order  in  which  the  validation  seript  determines  differenees;  see  Seetion  4. 1.1. 4  for  the 
exeeution  sequenee.  Table  7  eompares  various  file  types  and  the  output  fields  to 
summarize  whieh  combinations  are  affeeted  by  the  differences  elassified  in  the  following 
seetions.  The  table  is  also  useful  for  visualizing  the  seope  of  the  implementation  with 
regard  to  file  type  and  impaet  of  the  known  defieieneies. 


Table  7.  Field  differenees  versus  file  type. 


File  Type 

COMMAND 

PID 

USER 

FD+ 

mode 

TYPE 

DEVICE 

SIZE/ 

OFF 

NODE 

NAME 

cwd 

/ 

/ 

D1 

/ 

/ 

/ 

/ 

/ 

/ 

txt 

/ 

/ 

D1 

/ 

/ 

/ 

/ 

/ 

/ 

REG 

/ 

/ 

D1 

/ 

/ 

/ 

/ 

/ 

/ 

DIR 

/ 

/ 

D1 

/ 

/ 

/ 

D2 

/ 

/ 

CHR 

/ 

/ 

D1 

/ 

/ 

/ 

E7 

/ 

/ 

LINK 

/ 

/ 

D1 

/ 

E5 

/ 

/ 

/ 

/ 

FIFO 

/ 

/ 

D1 

/ 

/ 

E6 

/ 

/ 

/ 

VNODE 

(other) 

/ 

/ 

D1 

/ 

/ 

C3 

C3 

C3 

/ 

PSXSHM 

/ 

/ 

D1 

/ 

/ 

C2 

C2 

C2 

C2 

PSXSEM 

/ 

/ 

D1 

/ 

/ 

C2 

C2 

C2 

C2 

KOUEUE 

/ 

/ 

D1 

/ 

/ 

C2 

C2 

C2 

C2 

PIPE 

/ 

/ 

D1 

/ 

/ 

C2 

C2 

C2 

C2 

FSEVENT 

/ 

/ 

D1 

/ 

/ 

C2 

C2 

C2 

C2 

SOCKET 

/ 

/ 

D1 

/ 

C1 

C2 

C2 

C2 

C2 
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4. 1.2.1  Constraints. 


Constraints  are  defined  as  differenees  in  output  that  oeeur  due  to  system  design 
decisions.  As  described  in  Section  3.1.3,  the  volafox  open  files  module  has  several 
limitations  with  regard  to  handle  type  and  filesystem  tag. 

Cl.  The  Isof  subtype  for  socket  handles  cannot  be  determined.  A  value  of 
DTYPE_SOCKET  for  the  member  f  ilglob .  f  g_type  indicates  a  socket 
handle.  The  Isof  command  reports  a  number  of  subtypes  for  these  handles 
including:  systm,  unix,  IPv4,  IPv6,  rte,  key,  ndrv,  and  possibly  others 
that  were  not  observed  in  testing.  Sockets  are  assigned  the  generic  type  SOCKET 
in  the  volafox  open  files  output. 

C2.  Only  handles  subscribing  to  the  virtual  node  (vnode)  interface  are  fully  supported. 
A  value  of  DTYPE_VNODE  for  the  member  f  ileglob  .  fg_type  indicates  the 
vnode  interface  is  in  use  for  a  particular  handle.  Full  support  indicates  meaningful 
output  is  reported  for  all  nine  Isof  command  fields.  Non- vnode  handles  show 
the  value  ‘-1’  for  DEVICE,  SIZE/OEE,  NODE,  and  NAME  to  indicate  these 
fields  are  unsupported  in  the  volafox  open  files  output. 

C3.  Only  vnodes  tagged  HfS+  or  DEVES  are  firlly  supported.  A  value  of  VT_HES  or 
VT_DEVES  for  the  member  vnode. v_tag  indicates  a  supported  filesystem. 
The  Isof  command  fields  DEVICE,  SIZE/OEE,  and  NODE  are  defined  outside 
struct  vnode  and  therefore  unsupported  for  other  filesystems.  Unsupported 
fields  are  indicated  in  the  volafox  open  files  output  with  an  appropriate  value 
from  ECODE,  a  global  dictionary  defined  for  Isof  .  py. 

4. 1.2. 2  Deficiencies. 

Deficiencies  are  defined  as  differences  in  output  that  occur  due  to  known  bugs.  As 
described  in  Section  3.5,  the  volafox  open  files  module  has  two  open  issues. 

Dl.  The  Isof  USER  field  is  not  correctly  reported  for  all  processes  in  a  full  file 
listing.  This  problem  is  not  consistent  across  all  processes  and  the  volafox  open 
files  module  is  not  capable  of  detecting  its  occurrence. 

D2.  Size  of  the  /dev  directory  cannot  be  determined.  Handles  with  vnode  .  v_type 
of  VDIR  and  vnode  .  v_tag  of  VT_DEVES  such  as  /dev  show  the  value  ‘-1’ 
in  the  SIZE/OEE  field. 
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4.1.23  Explanations. 

Explained  differences  are  those  in  output  that  occur  due  to  reproducible 
idiosyncrasies  of  the  tools  used  for  capture  or  validation.  They  are  distinct  from  failures 
because  the  explanations  are  not  speculative,  and  the  differences  can  be  detected  using 
automation.  Explanations  E4,  E5,  and  E6  are  believed  to  be  bugs  in  the  OS  X  version  of 
the  Isof  program.  However,  because  Isof  is  defined  as  the  authoritative  standard  for 
measurement,  its  bugs  are  classified  as  explained  differences  rather  than  deficiencies. 

El.  The  UNIX  Isof  command  output  always  includes  the  Isof  command  and  its 
associated  handles,  whereas  a  memory  dump  does  not.  Eor  10.7  only,  the 
dependent  process  sudo  is  present  in  addition  to  Isof. 

E2.  Memory  captured  using  the  Mac  Memory  Reader  tool  (see  Section  2.4.2)  includes 
evidence  of  the  process  MacMemoryReader  and  its  dependency  image, 
whereas  output  from  the  Isof  command  does  not. 

E3.  Data  collected  using  capture  .  py  (4.4.3)  does  not  share  the  process  sh  because 
MacMemoryReader  and  Isof  are  executed  in  different  subprocesses. 

E4.  OS  X  duplicates  some  handles  in  a  full  listing  using  Isof.  Duplication  occurs  at 
least  once  per  listing.  Eigure  36  demonstrates  the  problem. 


$  sudo  Isof 


COMMAND 

PID 

USER 

ED 

TYPE 

DEVICE 

SIZE/OFF 

NODE 

NAME 

mds 

29 

root 

cwd 

DIR 

14,2 

1088 

2 

/ 

mds 

29 

root 

twd 

DIR 

14,2 

1088 

2 

/ 

Eigure  36.  Isof  handle  duplication. 

In  all  observed  cases,  the  file  descriptor  ‘twd’  (a  composite  of  cwd  and  txt) 
identifies  the  duplicate,  while  all  other  fields  remain  the  same. 

E5.  OS  X  reports  the  type  of  symbolic  links  as  ‘0012’  instead  of ‘LINK’  in  the  Isof 
TYPE  field.  The  keyword  ‘LINK’  is  specified  in  the  manpage  and  therefore  the 
volafox  open  files  module  reports  symbolic  links  using  that  label.  The  bug  has 
only  been  observed  in  the  10.7  version  of  OS  X. 
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E6.  OS  X  does  not  report  the  Isof  DEVICE  field  for  EIEO  type  files.  The  manpage 
does  not  diseuss  the  omission  and  the  volafox  open  files  module  ean  determine 
the  major  and  minor  deviee  number  for  EIEO  speeial  files. 

E7.  Execution  of  the  Isof  command  causes  the  offset  of  its  terminal  file  (ttys)  to 
grow.  Eor  cases  where  a  ttys  file  is  the  same  used  by  the  Isof  command,  any 
offset  difference  is  classified  as  E7  rather  than  E6. 

4. 1.2. 4  Failures. 

Eailures  are  defined  as  differences  in  output  not  already  accounted  for  by 
constraints,  deficiencies,  or  explanations  that  occur  due  to  asynchronous  data  collection 
or  implementation  artifact.  It  is  important  to  note  that  the  fault  causing  failure  is 
undefined  by  default.  Analysis  in  Section  4.2  indicates  that  in  most  cases  failure  is  a 
consequence  of  validation  accuracy  rather  than  an  error  in  the  volafox  open  files  module 
implementation. 

El.  Command  name  mismatch  (field:  COMMAND).  Adjusted  for  E2. 

E2.  Missing/extra  process  (field:  PID).  Adjusted  for  El,  E2,  and  E3. 

E3.  Missing/extra  file  descriptor  (field:  ED).  Adjusted  for  E2  and  E4. 

E4.  Eile  mode  mismatch  (field:  ED).  Adjusted  for  E3. 

E5.  Eile  type  mismatch  (field:  TYPE).  Adjusted  for  E3,  Cl  and  E5. 

E6.  Device  mismatch  (field:  DEVICE).  Adjusted  for  E3,  C2,  C3,  and  E6. 

E7.  Size/offset  mismatch  (field:  SIZE/OEE).  Adjusted  for  E3,  C2,  C3,  D2,  and  E7. 

E8.  Node  identifier  mismatch  (field:  NODE).  Adjusted  for  E3,  C2  and  C3. 

E9.  Pathname  mismatch  (field:  NAME).  Adjusted  for  E3,  C2. 

Username  mismatch  is  classified  as  D1  and  therefore  not  listed  as  a  failure.  It  is 
reported  in  the  results  after  adjustment  for  E2.  Reporting  failures  E2  and  E3  also  aligns 
the  process  and  handle  lists  of  each  file  respectively  for  the  remaining  failure  tests.  This 
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means,  for  example,  that  FI  does  not  report  eommand  name  mismatches  that  occur  due  to 
a  missing  process  because  F2  already  accounts  for  it. 


4,2  Results 

This  section  describes  the  experimental  setup  used  to  validate  the  volafox  open 
files  module,  summarizes  output  from  the  experiments,  and  provides  analysis  of  the 
results.  Experimental  data  is  partitioned  in  two  sets:  controlled  test  cases  collected  in  the 
lab  and  real-world  collections  from  physical  Mac  hardware.  Only  the  controlled  test  cases 
are  directly  considered  in  the  validation  of  the  tool,  but  the  real-world  data  is  maintained 
due  to  a  number  of  ancillary  conclusions  that  can  be  derived  from  it. 

4.2.1  Parameters. 

Parameters  specify  the  experimental  configurations  used  to  validate  the  tool. 

4. 2. 1.1  Common  Collection  Parameters. 

•  Development/analysis  platform:  iMac  (27-inch  Mid  2011),  10.7.x,  8  GB  RAM 

•  Volafox  base  version:  r52,  research  build  (with  open  fdes  support):  1 .0 

•  OS  X  version  (with  UNIX  1  sof  built-in) 

•  RAM  installed 

4. 2. 1.2  Controlled  Test  Case  Parameters. 

•  VMware  Fusion  version:  4.1.0 

•  Memory  capture  format:  *.vmem  (VMware  frozen  memory  file,  linear  format) 

•  Darwin  kernel  architecture 

4.2. 1.3  Real-world  Collection  Parameters. 

•  Darwin  kernel  architecture:  i386 

•  Mac  Memory  Reader  version:  3.0.0 

•  capture  .  py  build:  1.1 

•  Mac  hardware  (model  specification) 
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4.2.2  Factors. 


Factors  specify  the  subset  of  parameters  diseretely  varied  aeross  experiments. 

4.2. 2.1  Virtual  Machine  Configurations. 

1.  OS  X  version:  10.6.8 

Darwin  kernel  arehiteeture:  1386 
RAM  installed:  1  GB 

2.  OS  X  version:  10.6.0  Server 
Darwin  kernel  arehiteeture:  x86_64 
RAM  installed:  1  GB 

Note:  by  default,  10.6  Snow  Leopard  installs  a  32-bit  kernel  for  the  elient 
version.  OS  X  Server  was  therefore  used  instead  to  aehieve  this  eonfiguration. 

3.  OS  X  version:  10.7.3 

Darwin  kernel  arehiteeture:  1386 
RAM  installed:  2  GB 

4.  OS  X  version:  10.7.0 

Darwin  kernel  arehiteeture:  x86_64 
RAM  installed:  2  GB 

4.2. 2.2  Real-world  Machine  Configurations. 

1.  OS  X  version:  10.6.8 
RAM  installed:  3  GB 

Mae  Model:  MacBook  Pro  (15-inoh  Core  2  Duo),  S/N  eode:  X6A 

2.  OS  X  version:  10.6.8 
RAM  installed:  2  GB 

Mac  Model:  MaeBook  Air  (13-ineh,  Late  2010),  S/N  code:  DR2 

3.  OS  X  version:  10.6.8 
RAM  installed:  3  GB 

Mac  Model:  iMac  (20-ineh  Late  2006),  S/N  eode:  VUW 

4.  OS  X  version:  10.6.8 
RAM  installed:  4  GB 

Mac  Model:  MaeBook  Pro  (15-inoh,  Mid  2010),  S/N  eode:  AGU 

5.  OS  X  version:  10.6.8 
RAM  installed:  2  GB 

Mao  Model:  Mao  mini  (Early  2006),  S/N  eode:  U35 
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6.  OS  X  version:  10.6.8 
RAM  installed:  1  GB 

Mac  Model:  iMac  (24-inch  Mid  2007),  S/N  code:  X8A 

7.  OS  X  version:  10.6.8 
RAM  installed:  4  GB 

Mac  Model:  iMac  (27-inch,  Mid  2010),  S/N  code:  DB5 

8.  OS  X  version:  10.6.8 
RAM  installed:  4  GB 

Mac  Model:  MacBook  Pro  (13-inch,  Mid  2010),  S/N  code:  ATM 

9.  OS  X  version:  10.7.0 
RAM  installed:  4  GB 

Mac  Model:  MacBook  (13-inch  Early  2008),  S/N  code:  0P2 

10.  OS  X  version:  10.7.2 
RAM  installed:  2  GB 

Mac  Model:  MacBook  Air,  S/N  code:  18X 

4.2.3  Controlled  Test  Cases. 

Because  this  research  involves  implementation  of  a  novel  tool,  direct  validation  of 
the  results  is  inherently  problematic.  An  approximation  using  output  from  Isof 
therefore  demonstrates  the  capabilities  of  the  system  developed.  The  validation  method 
used  amounts  to  a  suite  of  software  test  cases  that  either  pass  or  fail.  Resulting  failures 
are  then  addressed  individually,  or  reclassified  in  the  difference  taxonomy  before  the 
suite  is  rerun.  Where  an  explanation  is  provided  for  a  failure,  the  discussion  must  be 
viewed  as  speculative  because  all  concrete  differences  identified  have  been  integrated 
with  the  taxonomy  described  in  Section  4.1.2.  Furthermore,  the  difficulty  in  defining, 
acquiring,  and  replicating  clean  memory  captures  means  no  statistical  rigor  can  be 
applied  to  the  validation.  The  majority  of  firm  numbers  from  test  results  are  therefore 
located  in  Appendix  E  to  avoid  the  inference  that  results  were  achieved  through 
performance  analysis. 
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As  stated  in  Section  3.1,  one  design  goal  for  the  system  implemented  is  to  provide 
coverage  for  a  breadth  of  operating  system  versions  and  kernel  architectures.  These  test 
cases  are  intended  to  demonstrate  that  coverage  by  representing  both  i386  and  x86_64 
Intel  architectures  over  the  span  of  minor  OS  X  versions  (10.6.0-8  and  10.7.0-3)  within 
the  current  and  previous  releases  of  the  operating  system.  All  tests  are  performed  on 
guest  installations  of  OS  X  running  as  a  virtual  machine.  This  setup  offers  the  linear  file 
format  volafox  requires  in  analyzing  64-bit  kernel  memory,  the  contents  of  which  are 
written  to  disk  when  the  VM  is  suspended.  Section  4. 1.1.1  describes  steps  taken  to 
minimize  operating  system  interference  with  the  state  of  open  files  during  collection. 

Table  8  shows  a  summary  of  the  results  provided  in  Appendix  E  (Table  15)  for 
the  first  controlled  test  case.  After  accounting  for  the  constraints,  deficiencies,  and 


Table  8.  OS  X  10.6.8  x86  test  case  summary. 


Diff 

Field 

A 

Count 

Details 

F1 

COMMAND 

0 

F2 

PID 

0 

D1 

USER 

5 

15%  of  usernames  misreported 

F3 

FD 

0 

F4 

mode 

0 

F5 

TYPE 

0 

F6 

DEVICE 

0 

process 

Terminal 

file 

/dev/ptmx 

F7 

SIZE/OFF 

1 

Isof 

0t421 

volafox 

0t452 

diff 

+31  bytes 

process 

notifyd 

file 

/usr/share/zoneinfo/America/New_York 

Isof 

266103 

F8 

NODE 

2 

volafox 

266579 

process 

notifyd 

file 

/usr/share/zoneinfo/UTC 

Isof 

226396 

volafox 

266606 

F9 

NAME 

0 
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explained  differences  listed  in  Section  4.1.2  (not  shown),  this  table  indicates  how  similar 
the  volafox  open  files  output  is  to  the  Isof  approximation. 

Table  8  indicates  the  username  deficiency  (Dl)  affects  a  substantial  number  of 
processes  reported.  The  file  size  failure  (F7)  is  for  the  pseudo-tty  device  opened  by 
process  Terminal.  The  Terminal  application  is  in  the  process  hierarchy  for  Isof, 
which  as  explained  in  E7  is  known  to  modify  some  ttys  device  offsets  during 
execution.  The  node  identification  failures  (F8)  are  both  files  related  to  time  zone  opened 
by  the  not  if  yd  process.  It  is  unclear  why  the  notification  server  would  make  changes 
to  these  files  during  Isof  execution,  however  the  behavior  has  been  observed  in  all 
controlled  test  cases. 

Table  9  shows  a  summary  for  the  second  controlled  test  case  (Appendix  E,  Table 
16).  The  offset  and  node  identification  failures  (F7,  F8)  are  the  same  process/file 
combinations  described  for  the  10.6.8  x86  results. 


Table  9.  OS  X  10.6.0  Server  x64  test  case  summary. 


Diff 

Field 

A 

Count 

Details 

Ft 

COMMAND 

0 

F2 

PID 

0 

D1 

USER 

6 

17%  of  usernames  misreported 

F3 

FD 

0 

F4 

mode 

0 

F5 

TYPE 

0 

F6 

DEVICE 

0 

F7 

SIZE/OFF 

1 

process 

file 

Isof 

volafox 

diff 

Terminal 

/dev/ptmx 

0t343 

0t360 
+17  bytes 

F8 

NODE 

1 

process 

file 

Isof 

volafox 

notifyd 

/usr/share/zoneinfo/UTC 

92583 

92789 

F9 

NAME 

0 
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Table  10.  OS  X  10.7.3  x86  test  ease  summary. 


Diff 

Field 

A 

Count 

Details 

Ft 

COMMAND 

0 

F2 

PID 

+1 

process:  launchdadd 
volafox:  146 

D1 

USER 

17 

38  %  of  usernames  misreported 

F3 

FD 

+3 

process:  launchd 
volafox:  8 

type:  SOCKET 

process:  launchd 
volafox:  46 

type:  SOCKET 

process:  launchd 
volafox:  82 
type:  PIPE 

F4 

mode 

0 

F5 

TYPE 

0 

F6 

DEVICE 

0 

F7 

SIZE/OFF 

1 

process:  Terminal 
file:  /dev/ptmx 

Isof:  0t446 
volafox:  0t508 
diff:  +62  bytes 

F8 

NODE 

1 

process:  notifyd 

file:  /usr/share/zoneinfo/UTC 

Isof:  86138 
volafox:  86347 

F9 

NAME 

0 

Table  10  shows  a  summary  for  the  third  controlled  test  case  (Appendix  E,  Table 
17).  The  extra  process  in  the  volafox  output  (F2)  is  a  daemon  with  the  highest  PID  in  the 
process  list.  It  therefore  appears  to  have  been  launched  after  executing  Isof .  Additional 
file  descriptors  in  the  volafox  output  (F3)  belong  to  launchd.  Because  the  launchd 
process  manages  all  other  daemons  (Singh,  2006b,  p.  38),  it  is  very  active  and  therefore 
volatile.  For  both  10.7.x  test  cases  the  Isof  and  launchd  processes  appear  to  be 
confounded.  The  offset  and  node  identification  failures  (F7,  F8)  are  the  same  process/file 
combinations  previously  described. 
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Table  11.  OS  X  10.7.0  x64  test  case  summary. 


Diff 

Field 

A 

Count 

Details 

Ft 

COMMAND 

0 

F2 

PID 

+1 

process:  launchdadd 
volafox:  147 

D1 

USER 

8 

19  %  of  usernames  misreported 

F3 

FD 

+4 

process:  launchd 
volafox:  8 

type:  SOCKET 

process:  launchd 
volafox:  79 

type:  SOCKET 

process:  launchd 
volafox:  85 
type:  PIPE 

process:  WindowServer 
volafox:  txt 
type:  REG 

device:  -6,  size:  -7,  node:  -8,  name:  -9/OaO 

F4 

mode 

0 

F5 

TYPE 

0 

F6 

DEVICE 

0 

F7 

SIZE/OFF 

1 

process:  Terminal 
file:  /dev/ptmx 

Isof:  0t455 
volafox:  0t509 
diff:  +54  bytes 

F8 

NODE 

1 

process:  notifyd 

file:  /usr/share/zoneinfo/UTC 

Isof:  86138 
volafox:  86347 

F9 

NAME 

0 

Table  1 1  shows  a  summary  for  the  last  controlled  test  case  (Appendix  E,  Table 
18).  Offset  and  node  identification  failures  (F7,  F8),  extra  process  (F2),  and  the  extra 
launchd  handles  (F3)  are  the  same  previously  discussed.  The  extra  WindowServer 
file  descriptor  appears  to  be  a  malformed  vnode.  All  members  within  the  structure  are 
invalid,  and  the  file  name  is  made  up  of  non-ASCII  characters.  This  case  does  call  into 
question  the  methodology  described  in  Section  3.2  for  determining  valid  descriptors  in 
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the  file  table.  Sinee  the  oeeurrenee  appears  to  be  isolated,  it  is  particularly  difficult  to 
debug  this  potential  implementation  failure.  One  possible  explanation  is  that  the  handle 
may  be  an  initialized  but  as-yet-unused  vnode  in  the  file  descriptor  table.  The  current  tool 
has  no  ability  to  detect  this  condition,  though  the  template  test  method  described  in 
Section  3.4.4  could  possibly  be  used  if  a  reliable  test  case  could  be  determined  for  the 
failure.  Luckily,  the  error  output  is  well-handled  and  therefore  a  human  analyst  should  be 
able  to  make  this  determination  with  ease  even  if  the  tool  cannot. 

Results  from  the  four  controlled  test  cases  yield  several  important  conclusions. 
First,  the  volafox  open  files  module  is  functional  for  kernels  utilizing  both  Intel  1386  and 
x86_64  architectures.  Second,  the  tool  provides  coverage  for  OS  X  10.6.x  Snow  Leopard 
and  10.7.x  Lion  operating  systems.  Third,  as  described  in  Section  3.5.1,  the  username 
deficiency  (Dl)  results  suggest  that  this  field  cannot  be  trusted  in  the  volafox  output. 
Finally,  the  low  number  of  unexplained  failures  suggests  the  implementation  is  successful 
under  the  definition  in  Section  4. 1 . 

4.2.4  Real-world  Data  Analysis. 

In  addition  to  the  controlled  test  cases  described  in  Section  4.2.2,  the  volafox  open 
files  module  was  also  tested  against  a  set  of  memory  collected  from  physical  machines. 
The  script  capture.py  was  developed  to  automate  the  collection  of  memory  using  the 
Mac  Memory  Reader  tool  described  in  Section  2.4.2  and  a  variety  of  incident  response 
data  from  Section  2.2.2  for  comparison.  These  real-world  collections  are  invaluable  for 
program  debugging  and  revealing  edge  cases  in  the  open  files  implementation  but  are  not 
well  suited  for  validation  for  several  reasons.  First,  because  failures  cannot  be  replicated 
it  is  difficult  to  determine  if  a  fault  is  caused  by  implementation  bug  or  validation 
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accuracy.  Second,  the  colleetion  time  required  by  Mae  Memory  Reader  (see  Appendix  F) 


assures  that  output  from  Isof  is  always  stale  when  eompared  to  a  dump  of  physical 
memory.  Finally,  the  real-world  data  available  does  not  eover  the  breadth  of  OS  versions 
and  kernel  arehiteetures. 

Appendix  F  summarizes  the  eollections  aequired  for  analysis.  As  diseussed  in 
Seetion  2.5.2,  revision  52  of  the  volafox  projeet  on  whieh  the  open  files  implementation 
is  based  does  support  the  Mac  Memory  Reader  output  format  direetly.  As  a  result,  only 
1386  eaptures  ean  be  analyzed  with  the  volafox  tool  and  only  after  eonversion  to  linear 
format  using  the  flatten. py  utility.  The  ten  qualifying  eaptures  are  listed  in  Seetion 
4.2.2  and  the  full  open  files  results  for  eaeh  is  available  in  Appendix  E. 


Table  12.  OS  X  10.6.8  eombined  real-world  results  (8  samples). 


Diff 

Description 

Quantity  or  %  Per  Sampie 

C1 

SOCKET  handles  cannot  be  subtyped 

15-22%  of  handles  affected 

C2 

Non-vnode  handles  are  not  fully  supported 

27-40%  of  handles  affected 

C3 

Non-HFS-n/DEVFS  vnodes  are  not  fully 
supported 

0-4%  of  handles  affected 

D1 

A  USER  field 

16-51%  of  usernames  misreported 

D2 

/dev  directory  cannot  be  sized 

0  handles  affected 

E1 

isof  process  is  not  shared 

1  process  removed 

E2 

MacMemoryReader  and  image  processes 
are  not  shared 

2  processes  removed 

E3 

sh  process  is  not  shared 

1  process  removed 

E4 

Duplicate  handles  labeled  FD;  ‘twd’ 

2-5  handles  removed 

E5 

LINK  handles  are  mislabeled 

0  handles  affected 

E6 

FIFO  handles  do  not  report  device  identifier 

0-2  handles  affected 

E7 

Isof  ttys  file  size  is  not  shared 

10  handles  affected 

Ft 

A  COMMAND  field 

0  commands  differ 

F2 

A  PID  field 

0-6%  of  processes  removed 

F3 

A  FD  field 

4-22%  of  handles  removed 

F4 

A  MODE  field 

0-2  modes  differ 

F5 

A  TYPE  field 

0-2  types  differ 

F6 

A  DEVICE  field 

0-2  device  identifiers  differ 

F7 

A  SIZE/OFF  field 

0-10%  of  sizes/offsets  differ 

F8 

A  NODE  field 

0-8%  of  node  identifiers  differ 

F9 

A  NAME  field 

0-3%  of  names  differ 
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Table  12  shows  a  combined  summary  of  the  real-world  results  for  32-bit  samples 
running  OS  X  10.6  Snow  Leopard  (Appendix  E,  Tables  19-26).  Because  the  hardware 
and  software  configurations  vary  greatly  between  collections,  the  data  points  represent 
different  sample  populations  that  cannot  be  aggregated  to  produce  valid  mean  or  standard 
deviation.  Instead,  the  range  of  each  constraint,  deficiency,  explained  difference,  and 
failure  is  reported  to  offer  a  general  impression  of  how  commonly  these  differences 
occur.  A  few  noteworthy  conclusions  emerge  from  this  analysis. 

1.  With  up  to  6%  of  processes  (F2)  and  22%  of  handles  (F3)  thrown  out  for 
comparison  during  alignment,  Isof  does  not  approximate  the  real-world  data 
very  closely.  This  observation  supports  the  earlier  statement  that  such  data  makes 
a  poor  choice  for  tool  validation. 

2.  The  set  of  non-vnode  handles  (sockets,  pipes,  semaphores,  etc.)  make  up  a 
significant  portion  of  the  Isof  results  (C2).  This  observation  highlights  one 
opportunity  for  future  work. 

3.  Unsupported  file  systems  (C3)  in  the  real-world  data  were  cross-referenced  with 
the  mount  information  also  collected  by  the  capture.py  script  to  determine 
which  types  should  be  considered  for  future  support.  The  results  included  one 
instance  each  of:  msdos  (FAT32  external  hard  drive),  cddafs  (responsible  for 
reading  audio  CDs),  and  ntf  s  (Apple  Bootcamp  installation  of  Windows). 

4.  As  concluded  previously,  high  occurrence  of  the  username  reporting  bug  (Dl) 
makes  the  results  of  the  USER  field  unreliable.  This  impacts  not  only  the  open 
files  module  in  volafox,  but  also  affects  the  process  listing  module  as  explained  in 
Section  3.5.1. 

5.  Explained  differences  (E1-E7)  and  the  /dev  sizing  deficiency  (D2)  do  not  affect 
a  large  number  of  processes  and  handles.  However,  they  are  enumerated  in  detail 
because  each  occurrence  is  an  important  data  cleaning  consideration  during 
validation  of  the  tool. 

6.  For  a  given  handle  the  size/offset  (F7)  and  node  identifier  (F8)  information  can  be 
particularly  volatile,  with  up  to  10  and  8  percent  change  observed  respectively. 
This  mirrors  the  failure  behavior  observed  across  test  cases  in  Section  4.2.3. 
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7.  Upon  inspection  of  the  failures  by  hand,  high  volatility  of  the  name  field  (F9)  was 
often  linked  to  two  applications:  Spotlight  and  the  Microsoft  suite.  Spotlight  is 
Apple’s  indexed  search  technology  and  automatically  begins  processing  external 
media  when  mounted.  Because  the  capture  .py  script  is  delivered  on  external 
media,  the  act  of  collection  increases  indexing  activity.  Spotlight  should  therefore 
be  an  important  consideration  during  incident  response  because  of  this  observed 
impact  to  the  state  of  open  files. 

Unlike  Snow  Leopard,  Lion  installs  a  64-bit  kernel  for  the  client  OS  by  default.  A 
32-bit  Lion  kernel  is  only  present  on  older  models  that  received  an  upgrade  installation  of 
Lion  from  32-bit  Snow  Leopard.  This  results  in  fewer  qualifying  samples  available  for 
analysis. 

Table  13  summarizes  the  remaining  real-world  results,  both  taken  from 
installations  of  32-bit  10.7  Lion  (Appendix  E,  Tables  27-28).  The  samples  are  from 
machines  running  different  minor  version  of  the  OS  and  therefore  are  grouped  only  for 


Table  13.  OS  X  10.7.x  combined  real-world  results  (2  samples). 


Diff 

Description 

Quantity  or  %  Per  Sampie 

C1 

SOCKET  handles  cannot  be  subtyped 

22%  of  handles  affected 

C2 

Non-vnode  handles  are  not  fully  supported 

35,36%  of  handles  affected 

C3 

Non-HFS-n/DEVFS  vnodes  are  not  fully 
supported 

1  handle  affected 

D1 

A  USER  field 

40,54%  of  usernames  misreported 

D2 

/dev  directory  cannot  be  sized 

1  handle  affected 

E1 

isof  process  is  not  shared 

1  process  removed 

E2 

MacMemoryReader  and  image  processes 
are  not  shared 

0*,2  processes  removed 

E3 

sh  process  is  not  shared 

0*,1  process  removed 

E4 

Duplicate  handles  labeled  FD;  ‘twd’ 

5  handles  removed 

E5 

LINK  handles  are  mislabeled 

3  handles  affected 

E6 

FIFO  handles  do  not  report  device  identifier 

0  handles  affected 

E7 

isof  ttys  file  size  is  not  shared 

0*,13  handles  affected 

Ft 

A  COMMAND  field 

0  commands  differ 

F2 

ARID  field 

4,10%  of  processes  removed 

F3 

A  FD  field 

11,14%  of  handles  removed 

F4 

A  MODE  field 

0,2  modes  differ 

F5 

A  TYPE  field 

0,2  types  differ 

F6 

A  DEVICE  field 

0,1  device  identifiers  differ 

F7 

A  SIZE/OFF  field 

1%  of  sizes/offsets  differ 

F8 

A  NODE  field 

0,1%  of  node  identifiers  differ 

F9 

A  NAME  field 

0,1%  of  names  differ 
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convenience.  Ranges  are  replaced  with  series  for  values  that  vary  since  there  are  only  two 
samples.  The  general  eonelusions  listed  from  the  10.6  analysis  remain  unehanged,  but 
there  are  a  few  interesting  highlights.  First,  the  10.7  results  include  the  unsupported 
filesystem  (C3)  mtmfs  used  to  implement  the  Mobile  Time  Machine  feature  unique  to 
Lion  (Siracusa,  2011).  Second,  the  E2,  E3,  and  E7  results  inelude  an  asterisk  because  one 
of  the  samples  experienced  an  interesting  eollection  failure.  The  capture.py  seript 
and  all  its  assoeiated  proeesses  (Python,  sh,  MacMemoryReader,  image,  ete.)  are 
all  eonspicuously  absent  from  the  volafox  output  for  the  18X  model  sample  (see  Seetion 
4.2.2  for  model  codes). 

The  real-world  data  identifies  a  number  of  implementation  problems  that  may  not 
have  been  encountered  otherwise.  In  addition  to  the  truncated  proeess  list  for  18X,  the 
U35  model  sample  eauses  a  previous  version  of  the  open  files  module  to  enter  an  infinite 
loop  due  to  a  self-referencing  process  in  the  linked  list.  These  two  cases  led  to  a  host  of 
new  exeeption  handling  eode  being  added  to  the  open  files  module.  Originally  for 
debugging  purposes,  the  new  warnings  reveal  an  abundance  of  broken  pointers  present 
throughout  the  real-world  samples.  Model  X8A  for  example  generated  over  1200 
warnings  alone,  though  this  was  an  extreme  ease. 

Since  the  invalid  pointer  warnings  were  not  observed  in  the  controlled  test  eases, 
two  explanations  are  postulated.  Eirst,  the  flatten. py  image  conversion  utility  may 
not  be  trustworthy,  or  there  exists  a  bug  in  the  Mac  Memory  Reader  capture  tool  itself. 
Second,  changes  to  the  layout  of  memory  made  during  eapture  may  result  in  instability  of 
the  linked  data  struetures  reflected  in  the  volafox  analysis.  Given  the  number  of  proeess 
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and  handle  changes  observed  from  memory  capture  to  Isof  execution  in  the  real-world 
results,  the  second  explanation  is  more  likely.  One  recommendation  to  mitigate  this 
problem  is  to  assure  memory  capture  proceeds  as  rapidly  as  possible.  As  indicated  in 
Appendix  F,  one  factor  affecting  speed  is  the  type  of  external  media  used  for  capture.  The 
results  show  a  16  Mb/s  average  increase  in  capture  speed  when  using  an  external  hard 
drive  over  flash  storage. 

4,3  Summary 

Section  4.1  of  this  chapter  introduces  the  evaluation  technique  used  to  validate  the 
results  of  the  volafox  open  files  module  by  comparison  with  approximate  output  from  the 
UNIX  Isof  command.  Sections  4.1.1  and  4.1.2  describe  the  methods  used  to  test  the 
tool  and  acquire  results.  Section  4.2  begins  with  an  overview  of  the  experimental 
parameters  and  factors  used  to  test  the  implementation.  Section  4.2.3  offers  an  analysis  of 
controlled  test  cases  used  to  validate  the  tool  across  the  breadth  of  designed  operating 
system  and  kernel  architecture  capabilities.  Section  4.2.4  closes  with  an  analysis  of 
results  from  a  set  of  real-world  data  collections. 

This  chapter  systematically  approaches  validation  of  the  volafox  open  files 
module  using  a  suite  of  controlled  software  test  cases.  The  number  of  failures  present 
after  cleaning  the  data  of  enumerated  constraints,  deficiencies,  and  explained  differences 
is  small  enough  to  permit  individual  analysis  of  the  faults.  Most  failures  can  be 
circumstantially  attributed  to  the  precision  of  the  validation  method,  with  one 
implementation  fault  outstanding.  Because  bugs  are  an  expected  element  of  any  complex 
software  system,  the  results  of  this  analysis  are  deemed  an  acceptable  research  outcome. 


95 


V,  Conclusions  and  Recommendations 


This  chapter  reviews  the  overall  conelusions  provided  by  the  new  volafox  open 
files  implementation  and  compares  researeh  results  with  stated  objectives.  Academie  and 
practical  contributions  of  the  work  are  emphasized.  Recommendations  for  future  researeh 
topics  related  to  forensie  memory  analysis  on  OS  X  are  also  provided.  Finally,  the  future 
of  the  open  source  volafox  projeet  extended  by  the  implementation  is  discussed. 

5,1  Research  Conclusions 

This  section  summarizes  researeh  results  and  the  key  conclusions  derived  in 
Chapter  4.  The  original  researeh  goal  and  supporting  objectives  from  Section  1.1  are 
restated  first  with  a  response  offered  for  eaeh. 

5.1.1  Research  Goal. 

Implement  and  document  a  capability  for  parsing  file  handles  from  raw 

memory  captured  on  OS  X. 

Success  -  the  volafox  open  files  module  implementation  documented  in  Seetion 
3.4  can  list  handles  associated  with  regular  files,  direetories,  symbolie  links,  FIFO,  and 
eharaeter  special  files.  Memory-mapped  files  for  the  proeess  executable  are  also  parsed 
along  with  the  current  working  direetory.  Test  results  are  favorable  on  raw  memory  from 
suspended  instances  of  OS  X  running  in  VMware  (Section  4.2.3)  and  memory  captured 
on  physical  hardware  using  the  Mac  Memory  Reader  tool  (Section  4.2.4). 
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5.1.2  Supporting  Objectives. 

Perform  design  recovery  of  the  data  structures  responsible  for  handling 
open  files. 

Success  -  the  research  implementation  effectively  leverages  the  data  structures 

and  references  described  in  Section  3.2  to  find  and  parse  file  handle  information.  Class 

structure  of  the  open  files  source  file  Isof  .py  is  organized  to  closely  resemble  that  of 

the  design  recovery  used  to  build  the  module  (Appendix  B,  D). 

Develop  a  flexible  process  for  programmatically  handling  structures 
defined  for  dijferent  kernel  architectures  and  operating  system  versions. 

This  necessitates  extensible  software  design  resilient  to  changes  in  future 
versions  of  OS  X. 

Success  -  the  data  structure  template  process  described  in  Sections  3.4.2  -  3.4.3 
effectively  parses  data  and  pointer  members  for  18  different  classes  written  for  the 
volafox  open  files  module.  Implementation  of  the  process  tested  favorably  against  two 
architectures  (i386,  x86_64)  and  two  major  versions  of  OS  X  (10.6  Snow  Leopard,  10.7 
Lion)  in  Section  4.2.3.  While  the  template  process  was  found  to  be  flexible  across  both 
tested  versions  of  OS  X,  future  extensibility  relies  on  consistent  naming  of  key  structure 
members  (Section  3.4.2).  Because  the  development  process  requires  kernel  headers 
defining  key  structures,  extensibility  is  also  dependent  on  the  open  source  availability  of 
the  kernel  code. 
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5.1.3  Additional  Research  Conclusions. 


Testing  the  implementation  also  produeed  several  additional  conelusions  not 
direetly  related  to  the  researeh  goal  and  its  supporting  objeetives.  First,  the  open  fdes 
module  does  not  reliably  output  the  correet  user  of  a  running  process,  as  verified  across 
all  controlled  and  real-world  test  cases  (Section  4.2).  No  fault  could  be  identified  in  the 
implementation,  nor  any  problem  with  the  kernel  structure  analysis  described  in  prior 
work  (Section  3.5.1).  The  deficiency  is  formally  listed  in  Section  4. 1.2.2  and  represented 
in  the  results.  Because  the  login  username  is  only  indirectly  related  to  the  file  handles 
through  the  process,  this  open  issue  does  not  affect  the  overall  research  outcome. 

Second,  due  to  the  time  required  for  memory  capture  on  physical  hardware, 
memory  analysis  tools  are  difficult  to  validate  on  real-world  data  (Section  4.2.4). 
Controlled  tests  using  virtual  machine  memory  images  should  therefore  be  used  in 
development. 

Third,  the  OS  X  indexed  search  technology.  Spotlight,  changes  numerous  handles 
in  response  to  the  mounting  of  external  media  (Section  4.2.4).  This  observation  should  be 
considered  during  incident  response  and  subsequent  analysis  if  the  memory  capture 
toolkit  is  delivered  via  mounted  filesystem. 

Finally,  memory  captured  on  physical  hardware  suffers  from  a  high  number  of 
invalid  pointer  references,  occasionally  resulting  in  malformed  linked-lists  (Section 
4.2.4).  Robust  exception  handling  should  be  implemented  to  address  this  problem  in  a 
memory  analysis  tool.  Collection  must  proceed  quickly  to  minimize  state  changes  during 
memory  copy  and  avoid  possible  loss  of  evidence.  External  hard  disk  is  preferable  to 
flash  media  due  to  faster  collection  speeds  (Appendix  F). 
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5,2  Significance  of  Research 

This  research  makes  three  primary  contributions  to  the  field  of  forensic  memory 
analysis  on  OS  X. 

Design  recovery  of  kernel  structures  related  to  open  files.  While  the  Darwin 
kernel  foundation  of  OS  X  is  open  source,  it  is  not  well  documented.  Structured  memory 
analysis  requires  knowledge  of  kernel  organization  that  must  be  traced  by  hand  from  the 
source  code.  The  description  of  data  structures  and  their  relationships  in  this  document 
will  be  of  use  to  anybody  seeking  to  implement  or  extend  extraction  of  OS  X  file  handles 
from  raw  memory. 

Dynamic  data  structure  templates.  The  repeatable,  general-purpose  process 
developed  to  build  structure  templates  for  a  range  of  architecture  and  operating  system 
configurations  can  be  applied  to  existing  and  future  volafox  modules.  It  may  also  prove 
extensible  to  future  versions  of  OS  X.  The  method  implemented  to  dynamically  select  the 
correct  template  for  a  given  memory  image  greatly  simplifies  the  programming  logic 
needed  to  support  multiple  configurations. 

Volafox  open  files  module  implementation.  Because  the  research  code  was 
designed  around  a  minimal  interface  to  the  existing  project  source,  the  new  module  can 
be  patched  against  the  latest  development  revision  with  little  or  no  refactoring.  The  full 
source  code  for  the  new  module  is  available  in  Appendix  G.  With  follow  on  efforts  to 
address  outstanding  constraints  and  deficiencies,  this  module  could  be  a  component  in  a 
comprehensive  tool  targeted  at  technical  users  and  forensic  analysts. 
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5,3  Recommendations  for  Future  Research 


The  problem  outlined  in  Chapter  1  emphasizes  use  of  forensic  memory  analysis  to 
replace  more  invasive  incident  response  methods.  Section  2.2.2  lists  seven  pieces  of 
information  that  National  Institute  of  Standards  and  Technology  (NIST)  specifies  should 
be  captured  during  the  volatile  collection  process.  Including  this  research,  volafox  now 
has  modules  to  support  four  of  the  seven  items.  For  maximum  impact,  future  OS  X 
memory  analysis  research  efforts  should  consider  the  remainder:  login  sessions,  network 
configuration,  and  operating  system  time. 

Constraints  and  deficiencies  of  the  research  implementation  for  listing  open  files. 
Sections  4. 1.2.1  and  4. 1.2.2  respectively,  enumerate  the  work  remaining  for  this  specific 
module.  Support  for  the  following  features  is  recommended  in  particular: 

1.  Identifying  process  ownership  -  the  inability  to  consistently  determine  the  user 
associated  with  a  particular  process  reduces  the  credibility  of  the  volafox  output 
and  also  its  usefulness.  A  process  normally  expected  to  run  in  userland  takes  on 
new  significance  when  observed  executing  as  root  for  example.  The  bug  is 
pervasive  as  it  affects  both  the  open  files  and  running  process  modules  in  volafox 
so  addressing  the  user  problem  is  a  priority. 

2.  Support  for  socket  handles  -  sockets  make  up  a  significant  portion  of  the 
unsupported  handle  types.  They  are  of  high  investigative  value  and  can  help 
identify  remote  activity  on  a  target  or  highlight  exfiltration  of  data.  Because  the 
capabilities  of  the  volafox  network  information  module  are  currently  limited 
(Section  2.5.2),  the  next  priority  in  handle  support  should  include  the  socket 
subtypes  (Section  4. 1 .2.1). 

3.  Additional  filesystem  support  -  real-world  test  results  identified  four  filesystems 
currently  unsupported  by  the  open  files  module:  msdos,  ntfs,  cddafs  and 
mtmf  s.  The  msdos  filesystem  (usually  FAT32)  is  a  common  choice  for  external 
media  that  must  be  interoperable  with  OS  X  and  Windows.  Though  ntfs  is 
mounted  read-only  by  OS  X,  mounts  may  be  present  if  a  Mac  is  partitioned  via 
Bootcamp  to  support  dual-boot  with  Windows.  Though  not  observed  in  testing, 
two  additional  network  filesystems  are  also  worth  considering.  The  proprietary 
Apple  Filing  Protocol  (AFP)  is  the  default  for  OS  X  filesharing  and  Common 
Internet  File  System  (CIFS)  is  used  for  shares  mounted  over  Samba. 
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One  final  suggestion  for  future  research  is  to  consider  the  performance  analysis  of 
memory  capture  speed,  the  interval  required  to  image  a  target,  as  it  relates  to  data 
structure  corruption.  This  research  assumes  the  occurrence  of  invalid  pointers  and  broken 
linked  data  structures  (looping  references,  incomplete  listings)  is  correlated  with  the  time 
required  to  image  physical  memory.  Exploring  this  relationship  further  might  offer 
important  insights  with  regard  to  the  development  of  efficient  tools  and  processes  for 
copying  physical  memory  for  forensic  analysis. 

5.3.1  Future  of  the  Volafox  Project. 

The  volafox  project  currently  suffers  from  a  lack  of  contributing  members  needed 
to  build  a  robust  forensics  capability  that  can  be  relied  upon  by  technical  users.  This 
thesis  represents  the  second  academic  work  to  extend  volafox  (Leat,  2011),  but  to  move 
beyond  the  research  domain  a  larger  community  is  required  to  develop  and  validate  the 
tool.  An  agenda  for  the  upcoming  Forensics  and  Incident  Response  Summit  (SANS 
Institute,  2012)  indicates  OS  X  memory  analysis  may  soon  be  added  to  the  Volatility 
framework.  Volatility  is  an  established  project  in  the  field  and  the  de  facto  standard  for 
open  source  forensic  memory  analysis.  Due  to  the  community  support  and  visibility,  it  is 
recommended  that  existing  work  from  volafox  be  integrated  with  the  future  OS  X  branch 
of  Volatility.  Because  volafox  borrows  extensively  from  the  Volatility  source,  the 
transition  should  not  require  major  refactoring. 
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5,4  Summary 

Section  5.1  restates  the  original  research  goal  and  its  supporting  objectives  before 
comparing  both  to  the  conclusions  provided  in  Chapter  4.  Testing  shows  the 
implementation  successfully  responds  to  the  research  goal  and  the  development  process 
offers  a  practical  demonstration  of  the  derived  objectives.  Section  5.2  describes  the  three 
significant  research  contributions:  design  recovery  of  kernel  structures  related  to  open 
files,  a  process  for  generating  and  selecting  dynamic  data  structure  templates,  and  the 
volafox  open  files  module  itself  Section  5.3  offers  recommendations  for  future  research 
related  to  OS  X  forensic  memory  analysis  and  the  future  of  the  volafox  project. 
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Appendix  A,  Regular  Builds  OS  X  10,4,4  -  10,7,3 


osx 

Build 

Date 

Darwin 

Notes 

10.4.4 

8G1165 

Jan  2006 

8.4 

http://support.apple.com/kb/HT2343 

10.4.5 

8G1454 

Feb  2006 

8.5 

http://support.apple.com/kb/HT2581 

10.4.6 

811119 

Apr  2006 

8.6 

http://support.apple.eom/kb/HT2200 

10.4.7 

8J2135a 

Jun  2006 

8.7 

http://support.apple.com/kb/TA24141 

10.4.8 

8L2127 

Sep  2006 

8.8 

http://support.apple.com/kb/TA24306 

10.4.9 

8P2137 

Mar  2007 

8.9 

http://support.apple.com/kb/HT1525 

10.4.10 

8R2232 

Jun  2007 

8.10 

http://support.apple.com/kb/HT  1 607 

10.4.11 

8S2167 

Nov  2007 

8.11 

http://support.apple.com/kb/TA24901 

10.5 

9A581 

Oct  2007 

9.0 

Retail  DVD  release; 
http://support.apple.com/kb/HT  1 633 

10.5.1 

9B18 

Nov  2007 

9.1 

http://support.apple.com/kb/HT1566 

10.5.2 

9C31 

Feb  2008 

9.2 

http://support.apple.com/kb/HT1327 

10.5.3 

9D34 

May  2008 

9.3 

http://support.apple.com/kb/HT1 141 

i  n  R  /I 

9E17 

Q  A 

http://support.apple.com/kb/HT1994 

\  U.0.4 

9E25 

jun  ^uuo 

y.4 

http://support.apple.com/kb/HT  1 633 

10.5.5 

9F33 

Sep  2008 

9.5 

http://support.apple.com/kb/HT2405 

9G55 

Dec  2008 

http://support.apple.com/kb/HT3194 

10.5.6 

9G66 

Jan  2009 

9.6 

Retail  DVD  release  (part  of  Mac  Box  Set); 
http://support.apple.com/kb/HT  1 633 

9G71 

http://support.apple.com/kb/HT3192 

10.5.7 

9J61 

May  2009 

9.7 

http://support.apple.com/kb/HT3397 

9L30 

http://support.apple.com/kb/HT  1 633 

10.5.8 

9L31a 

Aug  2009 

9.8 

http://support.apple.com/kb/HT3606 

9L34 

http://support.apple.com/kb/HT3607 

10A432 

Aug  2009 

inn 

Retail  DVD  release; 
http://support.apple.com/kb/HT  1 633 

\  u.o 

10A433 

\  U.U 

Server  retail  DVD  release; 
http://support.apple.com/kb/HT  1 633 

10.6.1 

10B504 

Sep  2009 

10.1 

http://support.apple.com/kb/HT3810 

10.6.2 

10C540 

Nov  2009 

10.2 

http://support.apple.com/kb/HT3874 

103 


10.6.3 

10D573 

Mar  2010 

10.3 

http://support.appie.com/kb/HT4014 

10D575 

Retaii  DVD  reiease; 
http://support.appie.com/kb/HT  1 633 

10D578 

Apr  2010 

http://support.appie.com/kb/DL1017 

10.6.4 

10F569 

Jun  2010 

10.4 

http://support.appie.com/kb/HT4150 

10F616 

http://support.appie.eom/kb/DL1050 

10.6.5 

10H574 

Nov  2010 

10.5 

http://support.appie.com/kb/HT4250 

10H575 

http://support.appie.com/kb/DL1327 

10.6.6 

10J567 

Jan  2011 

10.6 

http://support.appie.com/kb/HT4459 

10.6.7 

10J869 

Mar  2011 

10.7 

http://support.appie.com/kb/HT4472 

10.6.8 

10K540 

Jun  2011 

10.8 

http://support.appie.com/kb/HT  1 633 

10K549 

Jui  2011 

http://support.appie.eom/kb/DL1400 

10.7 

11A511,a 

Jui  2011 

11.0 

Retaii  Mac  App  Store  reiease; 
http://support.appie.com/kb/HT  1 633 

11A511S 

Aug  2011 

Retaii  USB  drive  reiease 

10.7.1 

11B26 

Aug  2011 

11.1 

http://support.appie.com/kb/HT4764 

10.7.2 

11C74 

Oct  201 1 

11.2 

http://support.appie.com/kb/HT4767 

10.7.3 

10D50 

Feb  2012 

11.3 

Reieases  b  and  d  have  been  observed,  symboi 
tabies  appear  to  be  interchangeabie; 
http://support.appie.com/kb/HT5048 

Notes: 

1.  This  information  iargeiy  summarized  from  Wikipedia  reiease  histories  for  10.4-10.7,  and 
the  Appie  knowiedgebase  articie  “Finding  your  Mac  OS  X  version  and  buiid  information” 
(http://support.appie.com/kb/HT 1 633). 

2.  There  are  aiso  numerous  hardware-specific  buiids  in  addition  to  those  iisted,  some  of 
which  are  avaiiabie  in  the  Appie  knowiedgebase  articie  “Mac  OS  X  versions  (buiids)  for 
computers”  (http://support.appie.com/kb/HT1 159). 

3.  Buiid  numbers  in  boid  are  those  encountered  in  the  course  of  this  research,  and  therefore 
ones  for  which  voiafox  couid  be  patched  to  support  using  the  data  coiiected. 
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Appendix  B,  Full  Structure  Diagram 


Appendix  C,  Python  struct  Library 


Figure  37  demonstrates  the  Python  standard  library  function  struct .  unpack 
as  utilized  by  the  open  fdes  module  unpacktype  ( )  wrapper.  The  function  is  used  to 
convert  C  structures  represented  as  binary  data  to  a  tuple  of  equivalent  Python  types. 
From  the  documentation  http://docs.python.org/library/struct.html; 

struct . unpack  ( frit,  string)*^ 


Unpack  the  string  (presumably  packed  by  pack  (fnt,  .  .  . ) ) 
according  to  the  given  format.  The  result  is  a  tuple  even  if  it 
contains  exactly  one  item.  The  string  must  contain  exactly  the 
amount  of  data  required  by  the  format  (len  (string)  must 
equal  calcsize  {fmt) ). 


Within  the  context  of  this  research  string  is  a  variable  read  from  file  using  either 
IA32PagedMemoryPae  or  IA32PML4MemoryPae,  whichever  object  class  volafox 
is  using  an  instance  of.  Return  value  of  len  (string)  is  the  number  of  bytes.  The  fmt 
string  literal  consists  of  format  characters  representing  primitive  C  types  from  Table  14, 


#  string:  char  (8-bit) 

#  int:  32  or  64-bit 

#  short:  16-bit 


STR  =  0 
INT  =  1 
SHT  =  3 


*  size 


def  unpacktype (binstr,  member,  mtype) : 
offset  =  member [1] 
size  =  member [2] 

fmt  =  ' ' 

if  mtype  ==  STR: 

fmt  =  str(size)  +  's' 
elif  mtype  ==  INT: 

fmt  =  'I'  if  size  ==  4  else  'Q' 
elif  mtype  ==  SHT: 
fmt  =  ' H ' 


return  struct . unpack (fmt,  binstr [ of f set : size+off set ])[ 0  ] 

Figure  37.  Simplified  Isof  .py  unpacktype  ( )  function. 
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any  of  which  can  be  preceded  by  an  integral  to  speeify  a  repeat  eount  (e.g.  Mh' 


'hhhh'  ).  Beeause  pointers  are  not  an  available  type,  the  format  '  I '  or  'Q'  is  used  to 
represent  a  32  or  64-bit  pointer  respeetively. 

The  struct  .unpack  funetion  performs  endian  eonversion  as  needed,  but  it  is 
not  eapable  of  handling  the  nuanees  of  byte  and  type  alignment  for  members  within  a 
struct.  Padding  must  therefore  be  explieitly  defined  in  the  format  string,  but  bytes  marked 
'x'  are  not  ineluded  as  items  in  the  output  tuple.  For  the  format  '2I392xI52sI ' 
output  would  consist  of  the  following  sequenee  of  types:  int,  int,  int,  string,  and  int. 


Table  14.  struct .  unpack  format  eharacters. 


Format 

C  Type 

Python  Type 

Standard 

Size 

X 

pad  byte 

no  value 

c 

char 

string  of  length  1 

1 

b 

signed  char 

integer 

1 

B 

unsigned  char 

integer 

1 

9 

Bool 

bool 

1 

h 

short 

integer 

2 

H 

unsigned  short 

integer 

2 

i 

int 

integer 

4 

I 

unsigned  int 

integer 

4 

1 

long 

integer 

4 

L 

unsigned  long 

integer 

4 

q 

long  long 

integer 

8 

Q 

unsigned  long  long 

integer 

8 

f 

float 

float 

4 

d 

double 

float 

8 

s 

char [ ] 

string 

p 

char [ ] 

string 
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Appendix  D.  Full  UML  Diagram 


I  utilities 

'-ECODE  :  diet 
-STR  :  int 
-INT  :  int 
-SHT  :  int 


-columnprint(  headerlist :  list,  contentlist :  list,  mszlist :  list  =  [] ) 
-unpacktype(  binstr :  str,  member :  tuple,  mtype  :  int )  :  * 
-dev_decode(dev_t :  int) :  str 
-printhex(binstr :  str) 

^cal!ingclas_s(caHing^fxn  ^  fjanie)_:_sjr _ 


«  abstract » 

_ Struct _ 

+mem  :  IA32*MemoryPae 

+verb  :  bool 

+arch  :  int 

+kvers  :  int 

-TEMPLATES  :  diet 

-template  :  diet 

-ssize  :  int 

-smem  :  str  {  binary  } 


+ _ init _ (addr :  int) 

-rvalidaddr(addr :  int)  :  bool 


The  eonstant  templates  is  an  | 
abstraet  statie  variable  whose  definition 
is  deferred  to  the  subelasses.  The  statie 
variable  template  is  ehosen  from 

TEMPLATES  at  runtime  by _ init _ ( ) 

based  on  the  value  of  arch  and  kvers. 


+ _ init _ (addr :  int) 

-i-getmode(fd  :  int) :  str 
-i-gettype() :  str 
-i-getoff():  int 

+getdata():  int  {  pointer } 


Fileproc 

-TEMPLATES  :  diet 

-I- init (addr :  int) 

-(■getfglobO  :  int  {  pointer } 

t 

Filedesc 

-TEMPLATES  :  diet 

-I- init (addr :  int) 

-(■getewdO  :  int  {  pointer } 
-i-getfglobs()  :  diet 


Session 

-TEMPLATES  :  diet _ 

+ _ init _ (addr :  int) 

-i-getuser() ;  str 

t 

Pgrp  ~ 

-TEMPLATES  :  diet _ 

+ _ init _ (addr :  int) 

-tgetuserO  :  str 

t 

I  Proc  ' 


-i-self_ptr :  int  {  pointer } 
-TEMPLATES  :  diet 
-head  :  int{  pointer} 
-filedese_ptr :  int  {  pointer } 
-exe_ptr :  int  {  pointer } 
-pgrp_ptr :  int  {  pointer } 

-pid:  int _ 

-I- _ init _ (int) 

-i-nextO  :  Proe 
+valid()  :  bool 
-i-setpid()  :  bool 
-i-getfd()  :  int{  pointer} 
-t-getpidO  :  int 
-(■getemdO  :  str 
-i-getuserO  ;  str 
-rgettxtQ  :  list _ 


I  Vm_map_entry 


-TEMPLATES  :  diet 


I  -pgettxt 


Vm_map 

-TEMPLATES  :  diet 

-I- init (addr :  int) 

-i-gettxtO  :  list 

t 

Task 

-TEMPLATES  :  diet 

-I- init (addr :  int) 

-pgettxtQ  :  list _ 


-TEMPLATES  :  diet 


+ _ init _ (addr :  int) 

:wetdev()  ;str _ 


Vnode 


-TEMPLATES  :  diet 
-VNODE  TYPE  :  list 
-VNODE  TAG  :  list 
-vtype  :  int 
-tag  :  int 
-xnode  :  'node 
-mount :  Mount 


+ _ init _ (addr ;  int) 

-rgetnodeO  :  int 
+getnameO  :  str 
-rgetdevO  :  str 
-rgetpathO  :  str 
-rgettype()  :  str 

-Hgetoff(fileglob_offset :  int) :  str 
-getparentO  :  int{  pointer } 

I 


_ Isof.py _ 

-rgetfilelistf  mem  :  IA32*MemoryPae,  areh  :  int,  kvers  :  int, 

proe_head  :  int  {  pointer },  pid  :  int,  vflag  :  int )  :  list 
-rprintfilelist(filelist :  list) 

-getfilelistbyproe(proe  :  Proe)  :  list _ 


-TEMPLATE 
-map  :  Vm_map 

-1 _ init _ (addr :  int) 

-rgettxtp  :  list _ 


Filefork 


-TEMPLATES  :  diet 


+ _ init _ (addr :  int) 

-rgetoffO  :  int _ 


Cnode 


-TEMPLATES  :  diet 


+ _ init _ (addr ;  int) 

+getnode() :  int 
-rgetentriesO  :  int 
-HgetoffQ  :  int _ 


Devnode 


-TEMPLATES  :  diet 


+ _ init _ (addr :  int) 

-rgetnodeO  :  int 


Mount 

-TEMPLATES  :  diet 

+ _ init _ (addr :  int) 

-rgetmountO  ;  str 
-HgetdevQ  :  str _ 


Appendix  E,  Full  Test  Results 


Table  15.  OS  X  10.6.8  x86  controlled  test  case  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

too 

624 

16.0 

handle 

F3 

C2 

TYPE:  not(vnode) 

239 

624 

38.3 

handle 

F3 

C3 

TYPE:  vnocle(other) 

0 

624 

0.0 

handle 

F3 

D1 

A  USER 

5 

34 

14.7 

process 

F2 

D2 

NAME: /dev 

0 

624 

0.0 

handle 

F3 

E1 

COMMAND:  lsof,sudo 

1  removed 

process 

E2 

N/A:  vm  capture 

E3 

E4 

FD:  twd 

1  removed 

handle 

E5 

TYPE:  link 

0 

624 

0.0 

handle 

F3 

E6 

TYPE:  fife 

0 

624 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

7 

624 

1.1 

handle 

F3 

Ft 

A  COMMAND 

0 

34 

0.0 

process 

F2 

F2 

A  PID 

-0 
+  0 

34 

34 

0.0 

0.0 

process 

El 

F3 

A  FD 

-0 
+  0 

624 

624 

0.0 

0.0 

handle 

F2,  E4 

F2 

F4 

A  MODE 

0 

624 

0.0 

handle 

F3 

F5 

A  TYPE 

0 

524 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

0 

385 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

1 

378 

0.3 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

2 

385 

0.5 

handle 

F3,C2,C3 

F9 

A  NAME 

0 

385 

0.0 

handle 

F3,C2 
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Table  16.  OS  X  10.6.0  Server  x64  eontrolled  test  case  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

98 

642 

15.3 

handle 

F3 

C2 

TYPE:  not(vnode) 

241 

642 

37.5 

handle 

F3 

C3 

TYPE:  vnocle(other) 

0 

642 

0.0 

handle 

F3 

D1 

A  USER 

6 

35 

17.1 

process 

F2 

D2 

NAME: /dev 

1 

642 

0.2 

handle 

F3 

E1 

COMMAND:  lsof,sudo 

1  removed 

process 

E2 

N/A:  vm  capture 

E3 

E4 

FD:  twd 

1  removed 

handle 

E5 

TYPE:  link 

0 

642 

0.0 

handle 

F3 

E6 

TYPE:  fife 

0 

642 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

7 

642 

1.1 

handle 

F3 

Ft 

A  COMMAND 

0 

35 

0.0 

process 

F2 

F2 

A  PID 

-0 
+  0 

35 

35 

0.0 

0.0 

process 

El 

F3 

A  FD 

-0 
+  0 

642 

642 

0.0 

0.0 

handle 

F2,  E4 

F2 

F4 

A  MODE 

0 

642 

0.0 

handle 

F3 

F5 

A  TYPE 

0 

544 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

0 

401 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

1 

393 

0.3 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

1 

401 

0.2 

handle 

F3,C2,C3 

F9 

A  NAME 

0 

401 

0.0 

handle 

F3,C2 

no 


Table  17.  OS  X  10.7.3  x86  controlled  test  case  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

140 

906 

15.5 

handle 

F3 

C2 

TYPE:  not(vnode) 

333 

906 

36.8 

handle 

F3 

C3 

TYPE:  vnode(other) 

0 

906 

0.0 

handle 

F3 

D1 

A  USER 

17 

45 

37.8 

process 

F2 

D2 

NAME:  /dev 

1 

906 

0.1 

handle 

F3 

E1 

COMMAND:  lsof,sudo 

2  removed 

process 

E2 

N/A:  vm  capture 

E3 

E4 

FD:  twd 

2  removed 

handle 

E5 

TYPE:  link 

3 

906 

0.3 

handle 

F3 

E6 

TYPE:  fife 

0 

906 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

7 

906 

0.8 

handle 

F3 

Ft 

A  COMMAND 

0 

45 

0.0 

process 

F2 

F2 

A  PID 

-0 
+  1 

45 

46 

0.0 

2.2 

process 

El 

F3 

A  FD 

-0 
+  3 

906 

909 

0.0 

0.3 

handle 

F2,  E4 

F2 

F4 

A  MODE 

0 

906 

0.0 

handle 

F3 

F5 

A  TYPE 

0 

763 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

0 

573 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

1 

565 

0.2 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

1 

573 

0.2 

handle 

F3,C2,C3 

F9 

A  NAME 

0 

573 

0.0 

handle 

F3,C2 

Ill 


Table  18.  OS  X  10.7.0  x64  controlled  test  case  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

133 

868 

15.3 

handle 

F3 

C2 

TYPE:  not(vnode) 

317 

868 

36.5 

handle 

F3 

C3 

TYPE:  vnode(other) 

0 

868 

0.0 

handle 

F3 

D1 

A  USER 

8 

43 

18.6 

process 

F2 

D2 

NAME: /dev 

1 

686 

0.1 

handle 

F3 

E1 

COMMAND:  lsof,sudo 

2  removed 

process 

E2 

K  [  /  A  .  . 

.  ^4.. 

E3 

VIM  udjjiuit; 

E4 

FD:  twd 

2  removed 

handle 

E5 

TYPE:  link 

3 

868 

0.3 

handle 

F3 

E6 

TYPE:  fife 

0 

686 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

7 

686 

0.8 

handle 

F3 

Ft 

A  COMMAND 

0 

43 

0.0 

process 

F2 

F2 

A  PID 

-0 

43 

0.0 

El 

+  1 

44 

2.3 

process 

F3 

A  FD 

0 

868 

0.0 

handle 

F2,  E4 

4 

872 

0.5 

F2 

F4 

A  MODE 

0 

868 

0.0 

handle 

F3 

F5 

A  TYPE 

0 

732 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

0 

551 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

1 

543 

0.2 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

1 

551 

0.2 

handle 

F3,C2,C3 

F9 

A  NAME 

0 

551 

0.0 

handle 

F3,C2 

112 


Table  19.  OS  X  10.6.8,  model  X6A  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

184 

1247 

14.8 

handle 

F3 

C2 

TYPE:  not(vnode) 

418 

1247 

33.5 

handle 

F3 

C3 

TYPE:  vnode(other) 

2 

1247 

0.2 

handle 

F3 

D1 

A  USER 

9 

56 

16.1 

process 

F2 

D2 

NAME: /dev 

0 

1247 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

2  removed 

E3 

COMMAND:  sh 

1  removed 

E4 

FD:  twd 

3  removed 

handle 

E5 

TYPE:  link 

0 

1247 

0.0 

handle 

F3 

E6 

TYPE:  fife 

0 

1247 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

10 

1247 

0.8 

handle 

F3 

F1 

A  COMMAND 

0 

56 

0.0 

process 

F2 

F2 

A  PID 

-0 

56 

0.0 

El 

+  2 

58 

3.4 

process 

F3 

A  FD 

-  21 

1268 

1.7 

handle 

F2,  E4 

+  68 

1315 

5.2 

F2 

F4 

A  MODE 

0 

1247 

0.0 

handle 

F3 

F5 

A  TYPE 

0 

1063 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

2 

827 

0.2 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

27 

817 

3.3 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

29 

827 

3.5 

handle 

F3,C2,C3 

F9 

A  NAME 

27 

829 

3.3 

handle 

F3,C2 

113 


Table  20.  OS  X  10.6.8,  model  DR2  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

208 

1364 

15.2 

handle 

F3 

C2 

TYPE:  not(vnode) 

419 

1364 

30.7 

handle 

F3 

C3 

TYPE:  vnode(other) 

0 

1364 

0.0 

handle 

F3 

D1 

A  USER 

22 

53 

41.5 

process 

F2 

D2 

NAME: /dev 

0 

1364 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

2  removed 

E3 

COMMAND:  sh 

1  removed 

E4 

FD:  twd 

4  removed 

handle 

E5 

TYPE:  link 

0 

1364 

0.0 

handle 

F3 

E6 

TYPE:  fife 

0 

1364 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

10 

1364 

0.7 

handle 

F3 

F1 

A  COMMAND 

0 

53 

0.0 

process 

F2 

F2 

A  PID 

-0 

53 

0.0 

El 

+  1 

54 

1.9 

process 

F3 

A  FD 

86 

1450 

5.9 

handle 

F2,  E4 

98 

1462 

6.7 

F2 

F4 

A  MODE 

1 

1364 

0.1 

handle 

F3 

F5 

A  TYPE 

1 

1156 

0.1 

handle 

F3,C1,E5 

F6 

A  DEVICE 

1 

945 

0.1 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

93 

935 

9.9 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

74 

945 

7.8 

handle 

F3,C2,C3 

F9 

A  NAME 

20 

945 

2.1 

handle 

F3,C2 

114 


Table  21.  OS  X  10.6.8,  model  VUW  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

186 

1065 

17.5 

handle 

F3 

C2 

TYPE:  not(vnode) 

369 

1065 

34.6 

handle 

F3 

C3 

TYPE:  vnode(other) 

37 

1065 

3.5 

handle 

F3 

D1 

A  USER 

22 

47 

46.8 

process 

F2 

D2 

NAME: /dev 

0 

1065 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

2  removed 

E3 

COMMAND:  sh 

1  removed 

E4 

FD:  twd 

4  removed 

handle 

E5 

TYPE:  link 

0 

1065 

0.0 

handle 

F3 

E6 

TYPE:  fife 

0 

1065 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

10 

1065 

0.9 

handle 

F3 

F1 

A  COMMAND 

0 

47 

0.0 

process 

F2 

F2 

A  PID 

- 1 

48 

2.1 

El 

+  2 

49 

4.1 

process 

F3 

A  FD 

-  116 

1181 

9.8 

handle 

F2,  E4 

+  146 

1211 

12.1 

F2 

F4 

A  MODE 

0 

1065 

0.0 

handle 

F3 

F5 

A  TYPE 

0 

879 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

0 

659 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

11 

649 

1.7 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

14 

659 

2.1 

handle 

F3,C2,C3 

F9 

A  NAME 

5 

696 

0.7 

handle 

F3,C2 
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Table  22.  OS  X  10.6.8,  model  AGU  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

163 

962 

16.9 

handle 

F3 

C2 

TYPE:  not(vnode) 

327 

962 

16.9 

handle 

F3 

C3 

TYPE:  vnode(other) 

0 

962 

0.0 

handle 

F3 

D1 

A  USER 

9 

42 

21.4 

process 

F2 

D2 

NAME: /dev 

0 

962 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

2  removed 

E3 

COMMAND:  sh 

1  removed 

E4 

FD:  twd 

2  removed 

handle 

E5 

TYPE:  link 

0 

962 

0.0 

handle 

F3 

E6 

TYPE:  fife 

0 

962 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

10 

962 

1.0 

handle 

F3 

F1 

A  COMMAND 

0 

42 

0.0 

process 

F2 

F2 

A  PID 

-  0 

42 

0.0 

El 

+  2 

44 

4.5 

process 

F3 

A  FD 

-34 

996 

3.4 

handle 

F2,  E4 

H-  22 

984 

2.2 

F2 

F4 

A  MODE 

0 

962 

0.0 

handle 

F3 

F5 

A  TYPE 

0 

799 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

0 

635 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

2 

625 

0.3 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

2 

635 

0.3 

handle 

F3,C2,C3 

F9 

A  NAME 

0 

635 

0.0 

handle 

F3,C2 
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Table  23.  OS  X  10.6.8,  model  U35  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

361 

1972 

18.3 

handle 

F3 

C2 

TYPE:  not(vnode) 

595 

1972 

30.2 

handle 

F3 

C3 

TYPE:  vnode(other) 

18 

1972 

0.9 

handle 

F3 

D1 

A  USER 

24 

60 

40.0 

process 

F2 

D2 

NAME: /dev 

0 

1972 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

2  removed 

E3 

COMMAND:  sh 

1  removed 

E4 

FD:  twd 

4  removed 

handle 

E5 

TYPE:  link 

0 

1972 

0.0 

handle 

F3 

E6 

TYPE:  fife 

2 

1972 

0.1 

handle 

F3 

E7 

NODE:  node(lsof) 

10 

1972 

0.1 

handle 

F3 

F1 

A  COMMAND 

0 

60 

0.0 

process 

F2 

F2 

A  PID 

-0 

60 

0.0 

El 

+  2 

62 

3.2 

process 

F3 

A  FD 

-26 

1998 

1.3 

handle 

F2,  E4 

+  51 

2023 

2.5 

F2 

F4 

A  MODE 

1 

1972 

0.1 

handle 

F3 

F5 

A  TYPE 

2 

1611 

0.1 

handle 

F3,C1,E5 

F6 

A  DEVICE 

0 

1357 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

6 

1349 

0.4 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

2 

1359 

0.1 

handle 

F3,C2,C3 

F9 

A  NAME 

2 

1377 

0.1 

handle 

F3,C2 
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Table  24.  OS  X  10.6.8,  model  X8A  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

366 

1633 

22.4 

handle 

F3 

C2 

TYPE:  not(vnode) 

645 

1633 

39.5 

handle 

F3 

C3 

TYPE:  vnode(other) 

1 

1633 

0.1 

handle 

F3 

D1 

A  USER 

38 

74 

51.4 

process 

F2 

D2 

NAME: /dev 

0 

1633 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

2  removed 

E3 

COMMAND:  sh 

1  removed 

E4 

FD:  twd 

5  removed 

handle 

E5 

TYPE:  link 

0 

1633 

0.0 

handle 

F3 

E6 

TYPE:  fife 

0 

1633 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

10 

1633 

0.0 

handle 

F3 

F1 

A  COMMAND 

0 

74 

0.0 

process 

F2 

F2 

A  PID 

- 1 

75 

1.3 

El 

+  1 

75 

1.3 

process 

F3 

A  FD 

-  150 

1783 

8.4 

handle 

F2,  E4 

+  17 

1650 

1.0 

F2 

F4 

A  MODE 

1 

1633 

0.1 

handle 

F3 

F5 

A  TYPE 

0 

1267 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

1 

987 

0.1 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

17 

977 

1.7 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

6 

987 

0.6 

handle 

F3,C2,C3 

F9 

A  NAME 

3 

988 

0.3 

handle 

F3,C2 

118 


Table  25.  OS  X  10.6.8,  model  DB5  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

280 

1672 

16.7 

handle 

F3 

C2 

TYPE:  not(vnode) 

598 

1672 

35.8 

handle 

F3 

C3 

TYPE:  vnode(other) 

22 

1672 

1.3 

handle 

F3 

D1 

A  USER 

22 

61 

36.1 

process 

F2 

D2 

NAME: /dev 

0 

1672 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

2  removed 

E3 

COMMAND:  sh 

1  removed 

E4 

FD:  twd 

2  removed 

handle 

E5 

TYPE:  link 

0 

1672 

0.0 

handle 

F3 

E6 

TYPE:  fife 

1 

1672 

0.1 

handle 

F3 

E7 

NODE:  node(lsof) 

10 

1672 

0.6 

handle 

F3 

F1 

A  COMMAND 

0 

1672 

0.0 

process 

F2 

F2 

A  PID 

-0 
+  0 

61 

61 

0.0 

0.0 

process 

El 

F3 

A  FD 

-  127 

+  50 

1799 

1722 

7.1 

2.9 

handle 

F2,  E4 

F2 

F4 

A  MODE 

0 

1672 

0.0 

handle 

F3 

F5 

A  TYPE 

0 

1392 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

0 

1051 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

38 

1042 

3.6 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

33 

1052 

3.1 

handle 

F3,C2,C3 

F9 

A  NAME 

11 

1074 

1.0 

handle 

F3,C2 
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Table  26.  OS  X  10.6.8,  model  ATM  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

471 

2794 

16.9 

handle 

F3 

C2 

TYPE:  not(vnode) 

765 

2794 

27.4 

handle 

F3 

C3 

TYPE:  vnode(other) 

1 

2794 

0.0 

handle 

F3 

D1 

A  USER 

12 

65 

18.5 

process 

F2 

D2 

NAME: /dev 

0 

2794 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

2  removed 

E3 

COMMAND:  sh 

1  removed 

E4 

FD:  twd 

3  removed 

handle 

E5 

TYPE:  link 

0 

2794 

0.0 

handle 

F3 

E6 

TYPE:  fife 

0 

2794 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

10 

2794 

0.0 

handle 

F3 

F1 

A  COMMAND 

0 

65 

0.0 

process 

F2 

F2 

A  PID 

- 1 

66 

1.5 

El 

+  3 

68 

4.4 

process 

F3 

A  FD 

-352 

3146 

11.2 

handle 

F2,  E4 

h-76 

2870 

2.6 

F2 

F4 

A  MODE 

2 

2794 

0.1 

handle 

F3 

F5 

A  TYPE 

2 

2323 

0.1 

handle 

F3,C1,E5 

F6 

A  DEVICE 

1 

2027 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

55 

2017 

2.7 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

49 

2027 

2.4 

handle 

F3,C2,C3 

F9 

A  NAME 

42 

2029 

2.1 

handle 

F3,C2 

120 


Table  27.  OS  X  10.7.0,  model  0P2  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

670 

3010 

22.3 

handle 

F3 

C2 

TYPE:  not(vnode) 

1087 

3010 

36.1 

handle 

F3 

C3 

TYPE:  vnode(other) 

1 

3010 

0.1 

handle 

F3 

D1 

A  USER 

36 

90 

40.0 

process 

F2 

D2 

NAME:  /dev 

1 

3010 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

2  removed 

E3 

COMMAND:  sh 

1 

removed 

E4 

FD:  twd 

5  removed 

handle 

E5 

TYPE:  link 

3 

3010 

0.1 

handle 

F3 

E6 

TYPE:  fife 

0 

3010 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

13 

3010 

0.4 

handle 

F3 

F1 

A  COMMAND 

0 

90 

0.0 

process 

F2 

F2 

A  PID 

-0 

90 

0.0 

El 

+  4 

94 

4.3 

process 

F3 

A  FD 

-308 

3318 

9.3 

handle 

F2,  E4 

H-  139 

3149 

4.4 

F2 

F4 

A  MODE 

2 

3010 

0.1 

handle 

F3 

F5 

A  TYPE 

2 

2337 

0.1 

handle 

F3,C1,E5 

F6 

A  DEVICE 

1 

1922 

0.1 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

27 

1908 

1.4 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

17 

1922 

0.9 

handle 

F3,C2,C3 

F9 

A  NAME 

14 

1923 

0.7 

handle 

F3,C2 
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Table  28.  OS  X  10.7.2,  model  18X  real-world  results  (1  sample). 


Diff 

Test 

Count 

Total 

% 

Unit 

Total  XRef 

C1 

TYPE:  socket 

542 

2469 

22.0 

handle 

F3 

C2 

TYPE:  not(vnode) 

869 

2469 

35.2 

handle 

F3 

C3 

TYPE:  vnode(other) 

1 

2469 

0.0 

handle 

F3 

D1 

A  USER 

38 

70 

54.3 

process 

F2 

D2 

NAME: /dev 

1 

2469 

0.0 

handle 

F3 

E1 

COMMAND:  Isof 

1  removed 

process 

E2 

COMMAND:  mmr, image 

0  removed 

E3 

COMMAND:  sh 

0  removed 

E4 

FD:  twd 

5  removed 

handle 

E5 

TYPE:  link 

3 

2469 

0.1 

handle 

F3 

E6 

TYPE:  fife 

0 

2469 

0.0 

handle 

F3 

E7 

NODE:  node(lsof) 

0 

2469 

0.0 

handle 

F3 

F1 

A  COMMAND 

0 

70 

0.0 

process 

F2 

F2 

A  PID 

-8 

78 

10.3 

El 

+  0 

70 

0.0 

process 

F3 

A  FD 

-290 

2759 

10.5 

handle 

F2,  E4 

+  7 

2476 

0.3 

F2 

F4 

A  MODE 

0 

2469 

0.0 

handle 

F3 

F5 

A  TYPE 

0 

1924 

0.0 

handle 

F3,C1,E5 

F6 

A  DEVICE 

0 

1599 

0.0 

handle 

F3,C2,C3,E6 

F7 

A  SIZE/OFF 

9 

1598 

0.6 

handle 

F3,C2,C3,D2,E7 

F8 

A  NODE 

5 

1599 

0.3 

handle 

F3,C2,C3 

F9 

A  NAME 

2 

1600 

0.1 

handle 

F3,C2 
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Appendix  F,  Hardware  Capture  Summary 


# 

Arch 

osx 

Type 

Model 

Media 

Time 

RAM  (GB) 

MB/S 

1 

i386 

10.6.8 

client 

AGU 

HDD 

02:39 

4 

25.8 

2 

i386 

10.6.8 

client 

ATM 

flash 

05:02 

4 

13.6 

3 

i386 

10.6.8 

client 

DB5 

HDD 

02:45 

4 

24.8 

4 

i386 

10.6.8 

client 

DR2 

flash 

02:37 

2 

13.0 

5 

i386 

10.6.8 

client 

U35 

flash 

02:32 

2 

13.5 

6 

i386 

10.6.8 

client 

VUW 

flash 

03:59 

3 

12.9 

7 

i386 

10.6.8 

client 

X6A 

HDD 

02:18 

3 

22.3 

8 

i386 

10.6.8 

client 

X8A 

HDD 

00:38 

1 

26.9 

9 

i386 

10.7.0 

client 

0P2 

HDD 

02:34 

4 

26.6 

10 

i386 

10.7.2 

client 

18X 

HDD 

01:24 

2 

24.4 

11 

x86_64 

10.6.8 

client 

M75 

HDD 

02:22 

4 

28.8 

12 

x86_64 

10.7.1 

server 

XYK 

HDD 

02:32 

4 

26.9 

13 

x86_64 

10.7.2 

client 

1G0 

HDD 

02:03 

4 

33.3 

14 

x86_64 

10.7.2 

client 

4R1 

HDD 

01:01 

2 

33.6 

15 

x86_64 

10.7.2 

client 

66D 

flash 

05:20 

4 

12.8 

16 

x86_64 

10.7.2 

client 

66E 

HDD 

01:55 

4 

35.6 

17 

x86_64 

10.7.2 

client 

ATM 

HDD 

01:55 

4 

35.6 

18 

x86_64 

10.7.2 

client 

D6H 

HDD 

01:56 

4 

35.3 

19 

x86_64 

10.7.2 

client 

H2H 

flash 

05:50 

4 

11.7 

20 

x86_64 

10.7.2 

client 

H2H 

HDD 

02:17 

4 

29.9 

21 

x86_64 

10.7.2 

client 

HJP 

flash 

05:56 

4 

11.5 

22 

x86_64 

10.7.2 

client 

HJP 

HDD 

02:39 

4 

25.8 

23 

x86_64 

10.7.2 

client 

HJW 

flash 

12:47 

8 

10.7 

24 

x86_64 

10.7.2 

client 

JWT 

HDD 

02:42 

4 

25.3 

25 

x86_64 

10.7.2 

client 

JWT 

HDD 

02:42 

4 

25.3 

26 

x86_64 

10.7.2 

client 

JWV 

flash 

07:46 

4 

8.8 

27 

x86_64 

10.7.2 

client 

JYC 

flash 

02:58 

2 

11.5 

28 

x86_64 

10.7.2 

client 

JYD 

flash 

06:36 

4 

10.3 

29 

x86_64 

10.7.2 

client 

JYD 

HDD 

02:38 

4 

25.9 

30 

x86_64 

10.7.2 

client 

MGG 

HDD 

02:39 

4 

25.8 

31 

x86_64 

10.7.2 

client 

MW8 

flash 

05:59 

4 

11.4 

32 

x86_64 

10.7.2 

client 

V13 

flash 

07:07 

4 

9.59 

33 

x86_64 

10.7.2 

client 

V7L 

HDD 

02:52 

4 

23.8 

34 

x86_64 

10.7.2 

client 

X92 

HDD 

01:30 

2 

22.8 

35 

x86_64 

10.7.2 

client 

YAM 

flash 

03:26 

2 

9.9 

36 

x86_64 

10.7.2 

client 

ZE2 

HDD 

03:20 

4 

20.5 

37 

x86_64 

10.7.2 

client 

ZE5 

HDD 

02:43 

4 

25.1 

38 

x86_64 

10.7.2 

server 

MFB 

flash 

08:49 

6 

11.6 

MIN: 

00:38 

1 

8.8 

MAX: 

12:47 

8 

35.6 

AVG  (flash): 

11.5 

AVG(HDD): 

27.4 

123 
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2 
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4 

5 

6 

7 

8 

9 

10 

11 
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14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 
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43 

44 

45 

46 

47 
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Appendix  G,  Complete  Source  Code:  Isof  .py 


#!/usr/bin/env  python 


Author : 
Last  Edit: 
Description: 


student  researcher,  osxmem@gmail.com 
31  Mar  2012 

Research  implementation  of  file  handle  support  for  volafox. 


Dependent:  x86.py  defines  read  and  is_valid_address  functions  for  the 

IA32PagedMemoryPae  object  passed  in  the  first  argument  of  getfilelist, 
though  it  is  not  an  import  dependency. 

Constraints: 

1.  NODE  field  will  only  be  returned  for  files  opened  on  HFS+  or  DEVFS  filesystems 

2.  Supported  filetypes:  VNODE 

3.  Supported  subtypes:  REG,  DIR,  CFIR,  LINK,  FIFO 

4.  No  Unicode  support  for  filenames  (8-bit  characters  only) 


Deficiencies : 

1.  USER  field  is  not  reported  correctly  for  many  processes  (mismatch  with  Isof  and  all 
user-related  keywords  of  ps  on  the  OSX  command  line) 

3.  Files  on  DEVFS  with  vnode  type  of  DIR  cannot  be  sized  (e.g  /dev) 

Notes: 

1.  All  struct  classes  MUST  have  at  least  one  element  in  their  template  dictionaries 
(even  if  not  fully  implemented  during  development)  or  there  will  be  serious 
performance  issues  as  the  size  is  sorted  out. 

Ill 


import  sys 
import  struct 
import  inspect 

from  sys  import  stderr 

#  error  codes  which  may  be  printed  in  the  program  output 
ECODE  =  { 

' unsupported' :  -1, 

'command':  -2, 

'pid':  -3, 

'fd':  -4, 

'type':  -5, 

'device':  -6, 

'size':  -7, 

'node':  -8, 

' name ' :  -9 

} 

#######################################  UTILITIES  ####################################### 
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#  convert  dev_t  (also  first  member  in  struct  fsid_t)  encoding  to  major/minor  device  IDs 
def  dev_decode(dev_t) : 

#  interpreted  from  the  major(x)  and  minor(x)  macros  in  bsd/sys/types . h 
maj  =  (dev_t  »  24)  &  255 

min  =  dev_t  &  16777215 
return  "%d,%d"  %(maj,  min) 

#  print  hex  representation  of  a  binary  string  in  8-byte  chunks,  four  to  a  line 
def  printhex(binstr) : 

hexstr  =  binstr .encode("hex") 

1  =  len(hexstr) 
i  =  0 

while  i  <  1: 

if  i+32  <  1: 

line  =  hexstr[i : i+32] 

else: 

line  =  hexstr[i:] 
out  =  "" 
j  =  0 

for  k  in  xrange(len(line)) : 
out  +=  line[k] 
if  j  ==  7: 

out  +=  '  ' 
j  =  0 

else: 

j  +=  1 

print  out 
i  +=  32 

#  print  a  string  matrix  as  a  formatted  table  of  columns 
def  columnprint(headerlist ,  contentlist,  mszlist=[]): 

num_columns  =  len(headerlist) 
size_list  =  [] 

#  start  sizing  by  length  of  column  titles 
for  title  in  headerlist: 

size_list.append(len(title)) 

#  resize  based  on  content 
for  i  in  xrange(num_columns) : 

for  line  in  contentlist: 

if  len(line)  !=  len(headerlist) : 

stderr .writeC'ERROR  length  of  header  list  does  not  match  content. \n") 
return  -1 

if  len(line[i])  >  size_list[i] : 
size_list[i]  =  len(line[i]) 

#  check  sizing  against  optional  max  size  list 
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if  len(mszlist)  >  0: 

if  len(mszlist)  !=  len(headerlist) : 

stderr.writeC'ERROR  length  of  header  list  does  not  match  max  size 


listAn") 


return  -1 

for  i  in  xrange(num_columns) : 

if  mszlist[i]  <  size_list[i]  and  mszlist[i]  >  0: 


#  -1/0  for  unrestricted 


sz 

mismatch  An") 


if  mszlist[i]  <  len(headerlist[i]): 

stderr .writeC'WARNING  max  size  list  and  column  header  length 

size_list[i]  =  mszlist[i] 


#  prepend  header  to  content  list 
contentlist  =  [headerlist]  +  contentlist 


#  build  comprehensive,  justified,  printstring 

printblock  =  "" 

for  line  in  contentlist: 

Printline  =  "" 

for  i  in  xrange(num_columns) : 
if  i  ==  0: 

Printline  +=  line[i][:size_list[i]] .ljust(size_list[i]) 
elif  i  ==  (num_columns-l) : 

Printline  +=  "  "  +  line[i][:size_list[i]] 

else: 

Printline  +=  line[i][:size_list[i]] .rjust(size_list[i]+l) 
printblock  +=  Printline  +  An' 


sys .stdout.writeC '%s'  %printblock) 

#  mtype  (enum) 

SIR  =0  #  string:  char  (8-bit)  *  size 

INT  =  1  #  int:  32  or  64-bit 

SHT  =  3  #  short:  16-bit 


#  return  unpacked  member  from  a  struct  given  its  memory  and  a  member  template 
def  unpacktype(binstr ,  member,  mtype): 
offset  =  member [1] 
size  =  member[2] 
fmt  =  " 


if  mtype  ==  SIR: 

fmt  =  str(size)  +  's' 
elif  mtype  ==  INT: 

fmt  =  'I'  if  size  ==  4  else  'Q' 
elif  mtype  ==  SHT: 
fmt  =  'H' 

else: 

calling_fxn  =  sys._getframe(l) 

Stderr.writeC'ERROR  %s.%s  tried  to  unpack  the  unknown  type  %d.\n" 
%(callingclass(calling_fxn) ,  calling_fxn . f_code. co_name,  mtype)) 
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return  None 


if  struct. calcsize(fmt)  !=  len(binstr[offset:size+offset]): 
calling_fxn  =  sys._getframe(l) 

stderr .writeC'ERROR  %s.%s  tried  to  unpack  '%s'  (fmt  size:  %d)  from  %d  bytes. \n" 
%(callingclass(calling_fxn) ,  calling_fxn.f_code.co_name,  fmt,  struct . calcsize(fmt) , 
len(binstr[offset: size+offset]))) 
return  None 

return  struct. unpack(fmt,  binstr[offset:size+offset])[0] 

#  return  the  enclosing  class  when  called  inside  a  function  (error  reporting) 
def  callingclass(calling_fxn) : 

try: 

classname  =  calling_fxn. f_locals[' self '] _ class _ name _ 

except  KeyError: 

classname  =  "<unknown>" 
return  classname 

####################################  PRIVATE  CLASSES  ##################################### 

#  parent  from  which  all  structures  derive,  an  abstract  class 
class  Struct(object) : 

#  static  variables  (common  to  all  structure  subclasses) 


mem 

=  None 

verb 

=  False 

arch 

=  -1 

kvers 

=  -1 

#  abstract  static  variables  (subclass-specific) 

TEMPLATES  =  None 
template  =  None 
ssize  =  -1 

def  validaddr(self ,  addr): 
if  addr  ==  0: 

calling_fxn  =  sys._getframe(l) 

stderr .writeC'WARNING  %s.%s  was  passed  a  NULL  address. \n" 
%(callingclass(calling_fxn) ,  calling_fxn . f_code . co_name)) 
return  False 

el if  not(Struct .mem. is_valid_address(addr)) : 
calling_fxn  =  sys._getframe(l) 

stderr .writeC'WARNING  %s.%s  was  passed  the  invalid  address  %.8x.\n" 
%(callingclass(calling_fxn) ,  calling_fxn.f_code.co_name,  addr)) 
return  False 
return  True 

def  _ init _ (self,  addr): 

self.smem  =  None 

if  self _ class _ template  ==  None: 
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#  configure  template  based  on  architecture  and  kernel  version 

if  Struct. arch  in  self _ class _ TEMPLATES: 

if  Struct. kvers  in  self _ class _ TEMPLATES[Struct.arch] : 

self _ class _ template  = 

self _ class _ TEMPLATES[Struct . arch] [Struct . kvers] 

else: 

stderr .writeC'ERROR  %s  has  no  template  for  x%d  Darwin  %d.x.\n" 

%(self class _ name ,  Struct. arch,  Struct . kvers)) 

sys.exitO 

else: 

stderr .writeC'ERROR  %s  does  not  support  %s  architecture .\n" 

%(self class _ name ,  str (Struct. arch))) 

sys  .exitO 

#  set  size  of  the  structure  by  iterating  over  template 

for  item  in  self _ class _ template. values() : 

if  (  item[l]  +  item[2]  )  >  self _ class _ ssize: 

self _ class _ ssize  =  item[l]  +  item[2] 

if  self .validaddr(addr): 

self.smem  =  Struct. mem. read(addr,  self _ class _ ssize); 

else: 

stderr .writeC'ERROR  instance  of  %s  failed  to  construct  with  address 
%.8x.\n"  %(self _ class _ name _ ,  addr)) 

#  Cnode  -->  Filefork 
class  Filefork(Struct) : 

TEMPLATES  =  { 

32:{ 

10 : { ' f f_data ' : (' struct 

cat_fork' ,16,96, ' ' ,{'cf_size' :Coff_t' ,16,8, 'SIZE/0FF(LINK)')})} 

,  11 ff_data ': C struct 

cat_fork' ,16,96, ' ' ,{'cf_size' :Coff_t' ,16,8, 'SIZE/0FF(LINK)')})} 

}, 

64:  { 

10 : { ' f f_data ' : (' struct 

cat_fork' ,32,96, ' ' ,{'cf_size' :Coff_t' ,32,8, 'SIZE/0FF(LINK)')})} 

,  11 ff_data ': C struct 

cat_fork' ,32,96, ' ' ,{'cf_size' :Coff_t' ,32,8, 'SIZE/0FF(LINK)')})} 

} 

} 

def  _ init _ (self,  addr): 

super( Filefork,  self) _ init _ (addr) 

def  getoff(self) : 

return  unpacktype(self .smem,  self . template[' ff_data '] [4] [' cf_size '] ,  INT) 

#  Vnode  -->  Cnode 
class  Cnode(Struct): 
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TEMPLATES  =  { 

32:{ 

10 : { ' c_desc ' : ( ' struct 

cat_desc' ,68,20, ' ' ,{'cd_cnid' :('cnid_t' ,80,4, 'NODE')}), 'c_attr' :('struct 

cat_attr' ,88,92, ' ' , { ' ca_fileid ' :('cnid_t' ,88,4, 'NODE'), 'ca_union2' :('union' ,140,4, 'entries 

->SIZE/OFF(dir) ' )}) , ' c_datafork' :('struct  filefork  *' ,204,4, ' ->datafork' )} 

,  ll:{'c_desc' :('struct 

cat_desc' ,72,20, ' ' ,{'cd_cnid' :('cnid_t' ,84,4, 'NODE')}), 'c_attr' :('struct 

cat_attr' ,92,92, ' ' , { ' ca_fileid ' :('cnid_t' ,92,4, 'NODE'), 'ca_union2' :('union' ,144,4, 'entries 

->SIZE/OFF(dir)')}), 'c_datafork' :('struct  filefork  *' ,208,4, ' ->datafork' )} 

}, 

64:  { 

10 : { ' c_desc ' : ( ' struct 

cat_desc' ,104,24, ' ' ,{'cd_cnid' :('cnid_t' ,116,4, 'NODE')}), 'c_attr' :('struct 

cat_attr' ,128,120, ' ' , { ' ca_fileid ' :('cnid_t' ,128,4, 'NODE'), 'ca_union2' :('union' ,204,4, 'entr 

ies->SIZE/OFF(dir)')}), 'c_datafork' :('struct  filefork  *' ,288,8, ' ->datafork')} 

,  ll:{'c_desc' :('struct 

cat_desc' ,112,24, ' ' ,{'cd_cnid' :('cnid_t' ,124,4, 'NODE')}), 'c_attr' :(' struct 

cat_attr' ,136,120, ' ' , { ' ca_fileid ' :('cnid_t' ,136,4, 'NODE'), 'ca_union2' :('union' ,212,4, 'entr 

ies->SIZE/OFF(dir)')}), 'c_datafork' :('struct  filefork  *' ,296,8, ' ->datafork')} 

} 

} 

def  _ init _ (self,  addr): 

super(Cnode,  self) _ init _ (addr) 

def  getnode(self) : 

return  unpacktype(self .smem,  self . template[' c_desc'] [4] [' cd_cnid'] ,  INT) 

def  getentries(self) :  #  used  to  calculate  size  for  DIR  files 

return  unpacktype( self .smem,  self . template[' c_attr '] [4] [' ca_union2'] ,  INT) 

def  getoff(self) :  #  returns  the  size  for  LINK  files 

datafork_ptr  =  unpacktype(self .smem,  self .template['c_datafork'] ,  INT) 
datafork  =  Filefork(datafork_ptr) 
return  datafork. getoff() 

#  Vnode  -->  Devnode 
class  Devnode(Struct): 

TEMPLATES  =  { 

32:{ 

10:{'dn_ino' :('ino_t' ,112,4, 'NODE(CHR)')} 

,  ll:{'dn_ino' :('ino_t' ,112,4, 'NODE(CHR)')} 

}, 

64:  { 

10:{'dn_ino' :('ino_t' ,192,8, 'NODE(CHR)')} 

,  ll:{'dn_ino' :('ino_t' ,192,8, 'NODE(CHR)')} 

} 

} 
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def  _ init _ (self,  addr): 

super(Devnode,  self) _ init _ (addr) 

def  getnode(self) : 

return  unpacktype(self .smem,  self .template['dn_ino'] ,  INT) 

#  Vnode  -->  Specinfo 
class  Specinfo(Struct) : 

TEMPLATES  =  { 

32:{ 

10:{'si_rdev' :('dev_t' ,12,4, '->DEVICE(CHR)')} 

,  ll:{'si_rdev' :('dev_t' ,12,4, '->DEVICE(CHR)')} 

}, 

64:  { 

10:{'si_rdev' :('dev_t' ,24,4, '->DEVICE(CHR)')} 

,  ll:{'si_rdev' :('dev_t' ,24,4, '->DEVICE(CHR)')} 

} 

} 

def  _ init _ (self,  addr): 

super(Specinfo,  self) _ init _ (addr) 

def  getdev(self): 

dev_t  =  unpacktype(self . smem,  self .template['si_rdev'] ,  INT) 
return  dev_decode(dev_t) 

#  Vnode  -->  Ubcinfo 
class  Ubcinfo(Struct): 

TEMPLATES  =  { 

32:{ 

10:{'ui_size' :('off_t' ,20,8, 'SIZE/0FF(REG)')} 

,  ll:{'ui_size' :('off_t' ,20,8, 'SIZE/0FF(REG)')} 

}, 

64 :{  #  NOTE:  10.6/7x64  offset  for  ui_size  edited  manually  32  -->  40 
10:{'ui_size' :('off_t' ,40,8, 'SIZE/0FF(REG)')} 

,  ll:{'ui_size' :('off_t' ,40,8, 'SIZE/0FF(REG)')} 

} 

} 

def  _ init _ (self,  addr): 

super(Llbcinfo,  self) _ init _ (addr) 

def  getoff(self): 

return  unpacktype(self .smem,  self . template[' ui_size ']  ,  INT) 

#  Vnode  -->  Mount 
class  Mount(Struct): 

TEMPLATES  =  { 

32:{ 
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10:{'mnt_vfsstat' :(' struct 

vfsstatfs' ,76,2152,"  :('fsid_t' ,132,8, ' ' ,{'val[0]':('int32_t',132,4,'- 

>DEVICE'), 'val[l]' :(' int32_t ', 136,4,  ")}),' f_mntonname churn ', 168, 1024, ' ->NAME ' )})} 
,  11: {'mnt_vfsstat struct 

vfsstatfs' ,76,2152,"  ,{'f_fsid' :('fsid_t' ,132,8, ' ' ,{'val[0]':('int32_t',132,4,'- 
>DEVICE'), 'val[l]' :(' int32_t ', 136,4,  ")}),' f_mntonname char [] ', 168, 1024, ' ->NAME ' )})} 
}, 

64:  { 

10:{'mnt_vfsstat' :(' struct 

vfsstatfs' ,136,2164, ' ' ,{'f_fsid' :('fsid_t' ,196,8,  "  ,{'val[0] ' :('int32_t' ,196,4,'- 
>DEVICE'), 'val[l]' :('int32_t' ,200,4,  ")}),' f_mntonname ':(' char [] ', 232, 1024, ' ->NAME ' )})} 
,  11: {'mnt_vfsstat ':(' struct 

vfsstatfs' ,132,2164, ' ' ,{'f_fsid' :('fsid_t' ,192,8,  "  ,{'val[0] ' :('int32_t' ,192,4,'- 
>DEVICE'), 'val[l]' :('int32_t' ,196,4,  ")}),' f_mntonname ':(' char [] ', 228, 1024, ' ->NAME ' )})} 
} 

} 

def  _ init _ (self,  addr): 

super(Mount,  self) _ init _ (addr) 

def  getmount(self): 

return  unpacktype(self . smem.  Mount . template['mnt_vfsstat '] [4] [' f_mntonname'] , 
SIR) . split( ' \x00 ' ,  1) [0] . strip( ' \x00 ' ) 

def  getdev(self): 

dev_t  =  unpacktype(self . smem. 

Mount. template ['mnt_vfsstat' ] [4] [' f_fsid'] [4] ['val[0] '] ,  INT) 
return  dev_decode(dev_t) 

#  Proc  -->  Vnode  (exe) 

#  Filesesc  -->  Vnode  (cwd) 

#  Fileglob  -->  Vnode 

#  Vnode  -->  Vnode  (parent) 
class  Vnode(Struct): 

TEMPLATES  =  { 

32:{ 

10:{'v_type' :('uintl6_t' ,68,2, 'TYPE(vnode)'), 'v_tag' :('uintl6_t' ,70,2, 'vfs- 
type'), 'v_un' :('union' ,76,4, '->ubc_info/specinfo'), 'v_name' :('const  char 
* ' ,116,4, ' NAME ' ) , ' v_parent ' : ( ' vnode_t ' ,120,4, ' - 

>vnode(parent)'), 'v_mount' :('mount_t' ,136,4, '->mount'), 'v_data' :('void  *' ,140,4, '- 
>cnode/devnode ' )} 

ll:{'v_type' :('uintl6_t' ,64,2, 'TYPE(vnode) ' ) , 'v_tag' :('uintl6_t' ,66,2, 'vfs- 
type'), 'v_un' :('union' ,72,4, '->ubc_info/specinfo'), 'v_name' :('const  char 
*' ,112,4, 'NAME'), 'v_parent' :('vnode_t' ,116,4, '- 

>vnode(parent) ' ) , 'v_mount' :('mount_t' ,132,4, '->mount'), 'v_data' :('void  *' ,136,4, '- 
>cnode/devnode ' )} 

}, 

64:  { 
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10:{'v_type' :('uintl6_t' ,112,2, 'TYPE(vnode) ' ) , 'v_tag' :('uintl6_t' ,114,2, 'vfs- 
type ' ) , ' v_un ' : ( ' union' ,120,8 , ' ->ubc_info/specinfo' ) , ' v_name' : ( ' const  char 
*' ,184,8, 'NAME'), 'v_parent' :C'vnode_t' ,192,8,  '- 

>vnode(parent) ' ) , 'v_mount' :('mount_t' ,224,8, '->mount'), 'v_data' :('void  *' ,232,8, '- 
>cnode/devnode ' )} 

ll:{'v_type' :('uintl6_t' ,104,2, 'TYPE(vnode)'), 'v_tag' :('uintl6_t' ,106,2, 'vfs- 
type'), 'v_un' :('union' ,112,8, ' ->ubc_info/specinfo' ) , 'v_name' :('const  char 
*' ,176,8, 'NAME'), 'v_parent' :('vnode_t' ,184,8, '- 

>vnode(parent)'), 'v_mount' :('mount_t' ,216,8, '->mount'), 'v_data' :('void  *' ,224,8, '- 
>cnode/devnode ' )} 

} 

} 


#  NOTE  1:  type  LINK  below  is  called  just  "LNK"  in  the  source  but  Isof  uses  "LINK" 

#  NOTE  2:  10.7  version  of  Isof  appears  to  be  broken  for  LINK  types,  it  outputs  the 

#  undocumented  type  "0012"  instead 

#  NOTE  3:  these  static  lists  defined  in  bsd/sys/vnode . h  but  modified  for  printing 
VNODE_TYPE  =  ["NON",  "REG",  "DIR",  "BLK",  "CHR",  "LINK",  "SOCK",  "FIFO",  "BAD", 

"STR",  "CPLX"] 

VN0DE_TAG  =  ['NON',  'UFS',  'NFS',  'MFS' ,  'MSDOSFS',  'LFS',  'LOFS',  'FDESC, 
'PORTAL',  'NULL',  'UMAP' ,  'KERNFS',  'PROOFS',  'AFS',  'ISOFS',  'UNION',  'NFS',  'ZFS', 
'DEVFS',  'WEBDAV,  'UDF',  'AFP',  'CDDA',  'CIFS',  'OTHER'] 


def  _ init _ (self,  addr): 

super(Vnode,  self) _ init _ (addr) 

self.vtype=  None 
self. tag  =  None 

seIf.xnode=  None  #  cnode,  devnode 
self. mount =  None 


def  getnode(self) : 

if  seif.xnode  ==  None: 

x_node_ptr  =  unpacktype(self .smem,  self .template['v_data'] ,  INT) 
if  self. tag  ==  None: 

self. tag  =  unpacktype(self . smem,  self .template['v_tag'] ,  SHT) 

if  self. tag  ==  16:  #  VT_HFS 

seif.xnode  =  Cnode(x_node_ptr) 


elif  self. tag  ==  18:  #  VT_DEVFS 

seif.xnode  =  Devnode(x_node_ptr) 


else: 

if  self. tag  <  Ien(Vnode . VN0DE_TAG) : 

s_tag  =  Vnode. VNODE_TAG[seIf. tag] 

else: 

s_tag  =  str(self .tag) 

stderr .writeC'WARNING  Vnode. getnode():  unsupported  FS  tag  %s, 
returning  %d.\n"  %(s_tag,  EC0DE['node'])) 
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return  EC0DE['node'] 


return  self .xnode.getnode() 
def  getname(self) : 

name_ptr  =  unpacktype(self .smem,  self .template ['v_name'] ,  INT) 

if  name_ptr  ==  0  or  not(Struct.mem.is_valid_address(name_ptr)): 
return  None 

#  NOTE:  this  may  be  trouble  for  the  255  UTF-16  filename  characters  HFS+  allows 
name_addr  =  Struct. mem. read(name_ptr,  255) 

name  =  struct. unpack('255s' ,  name_addr)[0] 
return  name. split( '\x00' ,  1)[0] . strip( '\x00' ) 

def  getparent(self) : 

parent_ptr  =  unpacktype(self .smem,  self .template['v_parent'] ,  INT) 

if  parent_ptr  ==  0  or  not(Struct.mem.is_valid_address(parent_ptr)): 

return  None 
return  parent_ptr 

def  getdev(self): 

if  self. tag  ==  None: 

self. tag  =  unpacktype(self .smem,  self .template['v_tag'] ,  SFIT) 
if  self. tag  ==  18:  #  CFIR 

vu_specinfo  =  unpacktype(self . smem,  self .template['v_un'] ,  INT) 

#  this  pointer  is  invalid  for  /dev  (special  case  DIR  using  VT_DEVFS) 
if  not(vu_specinfo  ==  0)  and  Struct. mem. is_valid_address(vu_specinfo): 
specinfo  =  Specinfo(vu_specinfo) 
return  specinfo. getdev() 

#  default  return  for  REG/DIR/LINK 
if  self. mount  ==  None: 

mount_ptr  =  unpacktype(self . smem,  self .template['v_mount'] ,  INT) 

if  mount_ptr  ==  0  or  not(Struct.mem. is_valid_address(mount_ptr)) : 
stderr .writeC'WARNING  Vnode. getdev():  v_mount  pointer  invalid, 
returning  %d.\n"  %ECODE['device']) 

return  ECODE['device'] 

self. mount  =  Mount(mount_ptr) 

return  self .mount. getdev() 

def  getpath(self) : 
path 

mntonname  =  "" 
parent  =  self 
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if  self. tag  ==  None: 

self. tag  =  unpacktype(self .smem,  self .template ['v_tag'] ,  SHT) 
if  self. mount  ==  None: 

mount_ptr  =  unpacktype(self . smem,  self .template['v_mount'] ,  INT) 

if  mount_ptr  ==  0  or  not(Struct.mem. is_valid_address(mount_ptr)) : 

stderr.writeC'WARNING  Vnode. getpath():  v_mount  pointer  invalid, 
returning  %d.\n"  %ECODE['name']) 

mntonname  =  str(ECODE['name']) 


else: 

self. mount  =  Mount(mount_ptr) 

if  self. mount  !=  None: 

mntonname  =  self .mount. getmount() 

while  True: 

parent_ptr  =  parent. getparent() 

if  parent_ptr  ==  0  or  not(Struct.mem.is_valid_address(parent_ptr)): 
break 

name  =  parent. getname() 
if  name  ==  None: 
break 

path  =  name  +  "/"  +  path 
parent  =  Vnode(parent_ptr) 

if  len(path)  <2:  #  file  is  root 

return  mntonname 

if  len(mntonname)  ==  1:  #  mount  is  root,  delete  trailing  slash 

return  mntonname  +  path[:-l] 

return  mntonname  +  "/"  +  path[:-l]  #  mount  +  path,  delete  trailing  slash 
def  gettype(self) : 

if  self.vtype  ==  None: 

self.vtype  =  unpacktype(self .smem,  self .template['v_type'] ,  SHT) 

if  self.vtype  <  len(Vnode.VNODE_TYPE): 

return  Vnode . VNODE_TYPE [self . vtype] 

return  -1  #  check  for  this  in  the  Vnode_pager  validation 

def  getoff(self,  fileglob_offset) : 

if  self.vtype  ==  None: 

self.vtype  =  unpacktype(self .smem,  self .template['v_type'] ,  SHT) 
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if  self. tag  ==  None: 

self. tag  =  unpacktype(self .smem,  self .template ['v_tag'] ,  SHT) 

#  NOTE:  UBC  information  not  valid  for  vnodes  marked  as  VSYSTEM 
if  self.vtype  ==  1:  #  REG 

ubcinfo_ptr  =  unpacktype(self . smem,  self .template['v_un'] ,  INT) 

if  ubcinfo_ptr  ==  0  or  not(Struct.mem. is_valid_address(ubcinfo_ptr)) : 

stderr .writeC'WARNING  Vnode. getoff():  v_un  pointer  invalid,  returning 
%d.\n"  %(ECODE['size'])) 

return  ECODE['size'] 

ubcinfo  =  Ubcinfo(ubcinfo_ptr) 
return  ubcinfo. getoff() 

elif  self. tag  ==  16:  #  VT_HFS 

if  self.xnode  ==  None: 

x_node_ptr  =  unpacktype(self . smem,  self .template['v_data'] ,  INT) 
self.xnode  =  Cnode(x_node_ptr) 

if  self.vtype  ==  2:  #  DIR 

entries  =  self .xnode.getentries() 

return  (entries  +  2)  *  34  #  AVERAGE_HFSDIRENTRY_SIZE :  bsd/hfs/hfs . h 

elif  self.vtype  ==  5:  #  LINK 

return  self .xnode.getoff() 

elif  self.vtype  ==  7:  #  FIFO 

return  "0t%i"  %fileglob_offset 

elif  self. tag  ==  18:  #  VT_DEVFS 

if  self.vtype  ==  4:  #  CFIR 

return  "0t%i"  %fileglob_offset 

elif  self.vtype  ==  2:  #  /dev 

return  "-1"  #  not  returning  ECODE  because  this 

deficiency  known 

if  self. tag  <  len(Vnode. VN0DE_TAG) : 

s_tag  =  Vnode. VNODE_TAG[self. tag] 

else: 

s_tag  =  str(self .tag) 
if  self.vtype  <  len(Vnode.VNODE_TYPE): 

s_type  =  Vnode. VNODE_TYPE [self .vtype] 

else: 

s_type  =  str(self. vtype) 

stderr .writeC'WARNING  Vnode. getoff():  unsupported  type  %s,  tag  %s.  Returning 
%d.\n"  %(s_type,  s_tag,  ECODE['size'])) 
return  ECODE['size'] 

#  Fileproc  -->  Fileglob 
class  Fileglob(Struct) : 
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TEMPLATES  =  { 

32:{ 

10 : { ' f g_f lag ' : ( ' i nt32_t ',16,4,' MODE ' ) , ' f g_type ' : ( ' f ile_type_t ',20,4,' FTYPE ' ) , ' f g_of f 
set' : ( 'off_t ' ,40,8 , ' SIZE/OFF ' ) , ' fg_data' : ( ' caddr_t ',48,4,' ->vnode' )} 

ll:{'fg_flag' :('int32_t' ,16,4, 'MODE'), 'fg_type' :('file_type_t' ,20,4, 'FTYPE'), 'fg_off set' :( 
' of f _t ', 40 , 8 ,' SIZE/OFF '), ' f g_data ' : ( ' caddr_t ',48,4,' ->vnode ' )} 

}, 

64:  { 

10 : { ' f g_f lag ' : ( ' i nt32_t ',32,4,' MODE ' ) , ' f g_type ' : ( ' f ile_type_t ',36,4,' FTYPE ' ) , ' f g_of f 
set ' : ( ' of f _t ', 64 , 8 ,' SIZE/OFF '), ' f g_data ' : ( ' caddr_t ',72,8,' ->vnode ' )} 

ll:{'fg_flag' :('int32_t' ,32,4, 'MODE'), 'fg_type' :('file_type_t' ,36,4, 'FTYPE'), 'fg_off set' :( 
' of f _t ', 64 , 8 ,' SIZE/OFF '), ' f g_data ' : ( ' caddr_t ',72,8,' ->vnode ' )} 

} 

} 


#  global  defined  in  bsd/sys/file_internal . h  but  modified  to  match  Isof  output 
FILE_TYPE  =  ["-1",  "VNODE",  "SOCKET",  "PSXSHM",  "PSXSEM",  "KQUEUE",  "PIPE", 
"FSEVENT"] 

MODE  =  ["  ",  "r  ",  "w  ",  "u  "] 


def  _ init _ (self,  addr): 

super(Fileglob,  self) _ init _ (addr) 

self. f type  =  None 

def  getmode(self ,  fd): 

self.ftype  =  unpacktype(self .smem,  self .template['fg_type'] ,  INT) 
filemode  =  " 


#  NOTE:  in  limited  Isof  testing  types  known  to  include  file  mode  reporting  are: 

#  VNODE,  SOCKET,  PSXSHM,  PSXSEM,  and  KQUEUE.  Others  do  not  append  any 

#  character  to  the  FD  identifier, 
if  self.ftype  in  xrange(l,6): 

flag  =  unpacktype(self .smem,  self .template['fg_flag'] ,  INT) 
filemode  =  Fileglob. MODE [flag  &  3] 

return  str(fd)+filemode 

def  gettype(self) : 

if  self.ftype  ==  None: 

self.ftype  =  unpacktype(self .smem,  self .template['fg_type'] ,  INT) 

if  self.ftype  <  0  or  self.ftype  >  (  len(Fileglob. FILE_TYPE)  -1  ): 

stderr .writeC'WARNING  Fileglob. gettype():  unknown  file  type  %d,  excluding 
this  result. \n"  %self.ftype) 

return  -1  #  check  for  this  in  the  getfilelistbyproc() 
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return  Fileglob. FILE_TYPE[self .ftype] 
def  getoff(self): 

return  unpacktype(self .smem,  self . template[' fg_offset '] ,  INT) 
def  getdata(self) : 

data_ptr  =  unpacktype( self .smem,  self .template['fg_data'] ,  INT) 

if  self .validaddr(data_ptr): 

return  data_ptr 
return  None 

#  Filedesc  -->  Fileproc 
class  Fileproc(Struct) : 

TEMPLATES  =  { 

32:{ 

10: {'f_f glob' :(' struct  fileglob  *' ,8,4, ' ->fileglob')} 

,  11: {'f_fglob' :(' struct  fileglob  *' ,8,4, ' ->fileglob')} 

}, 

64:  { 

10: {'f_f glob' :(' struct  fileglob  *' ,8,8, ' ->fileglob')} 

,  11: {'f_fglob' :(' struct  fileglob  *' ,8,8, ' ->fileglob')} 

} 

} 

def  _ init _ (self,  addr): 

super( Fileproc ,  self) _ init _ (addr) 

def  getfglob(self): 

fileglob_ptr  =  unpacktype(self .smem,  self .template['f_fglob'] ,  INT) 

if  self .validaddr(fileglob_ptr): 

return  fileglob_ptr 
return  None 

#  Proc  -->  Filedesc 
class  Filedesc(Struct) : 

TEMPLATES  =  { 

32:{ 

10: {'fd_of lies ':(' struct  fileproc  **',0,4,'- 
>fileproc[] ' ), 'fd_cdir ' :(' struct  vnode  * ' ,8,4, ' ->CWD') , ' fd_lastfile' : ( ' int ' , 20,4, ' - 
>fileproc[LAST_INDEX] ' )} 

,  11: {'fd_of lies ':(' struct  fileproc  **',0,4,'- 
>fileproc[] ' ), 'fd_cdir ' :(' struct  vnode  * ' ,8,4, ' ->CWD') , ' fd_lastfile' :(' int ', 20,4, ' - 
>fileproc[LAST_INDEX] ' )} 

}, 

64:  { 

10: {'fd_of ties ':(' struct  fileproc  **',0,8,'- 
>fileproc[] ' ), 'fd_cdir ' :(' struct  vnode  * ' ,16,8, ' ->CWD' ), ' fd_lastfile ' :(' int' ,36,4, ' - 
>fileproc[LAST_INDEX] ' )} 
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,  11: {'fd_ofiles struct  fileproc  **',0,8,'- 
>fileproc[] ' ), 'fd_cdir' :(' struct  vnode  * ' ,16,8, ' ->CWD' ), ' fd_lastfile ' :(' inf ,36,4, ' - 
>fileproc[LAST_INDEX] ' )} 

} 

} 

def  _ init _ (self,  addr): 

super(Filedesc,  self) _ init _ (addr) 

def  getcwd(self): 

cwd_ptr  =  unpacktype(self . smem,  self .template[' fd_cdir '] ,  INT) 
if  self . validaddr(cwd_ptr) : 

return  cwd_ptr 
return  None 

def  getfglobs(self) : 

#  sometimes  the  fd  is  valid,  but  this  array  address  is  not  (e.g.  kernel_task) 
ofiles_ptr  =  unpacktype(self .smem,  Filedesc.template['fd_ofiles'] ,  INT) 

if  ofiles_ptr  ==  0  or  not(Struct.mem.is_valid_address(ofiles_ptr)): 
return  None 

#  construct  a  list  of  addresses  from  the  fd_ofiles  array 

fd_lastfile  =  unpacktype(self . smem,  Filedesc.template['fd_lastfile'] ,  INT) 

ptr_size  =  4  if  (Struct. arch  ==  32)  else  8 

fmt  =  'I'  if  (Struct. arch  ==  32)  else  'Q' 

fglobs  =  {} 

for  i  in  xrange(fd_lastfile+l) : 

#  **fd_ofiles  is  an  array  of  pointers,  read  address  at  index  i 
fileproc_ptr  =  Struct. mem. read(ofiles_ptr+(i*ptr_size) ,  ptr_size) 
fileproc_addr  =  struct. unpack(fmt,  fileproc_ptr)[0] 

#  not  every  index  points  to  a  valid  file 

if  fileproc_addr  ==  0  or  not(Struct.mem. is_valid_address(fileproc_addr)) : 
continue 

fileproc  =  Fileproc(fileproc_addr) 
fileglob_ptr  =  fileproc. getfglob() 

if  fileglob_ptr  !=  None: 

fglobs[i]  =  fileglob_ptr 

return  fglobs 

#  Vm_object  -->  Vnode_pager 
class  Vnode_pager(Struct): 

TEMPLATES  =  { 

32:{ 

10:{'vnode_handle' :('struct  vnode  *' ,16,4, '->txf )} 

,  ll:{'vnode_handle' :('struct  vnode  *' ,16,4, '->txf )} 
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}, 

64 :{  #  NOTE:  10.6/7x64  offset  for  vnode_pager  edited  manually  24  -->  32 
10:{'vnode_handle' :('struct  vnode  *' ,32,8, '->txt')} 

,  ll:{'vnode_handle' :('struct  vnode  *' ,32,8, '->txt')} 

} 

} 

def  _ init _ (self,  addr): 

super(Vnode_pager,  self) _ init _ (addr) 

def  gettxt(self) : 

txt_ptr  =  unpacktype(self . smem,  self .template['vnode_handle'] ,  INT) 

#  self  may  not  actually  be  a  vnode  pager  (there  are  other  valid  types),  need  to 

#  run  several  tests  without  generating  warnings  to  be  sure, 
if  txt_ptr  ==  0  or  not(Struct.mem.is_valid_address(txt_ptr)): 

return  None 

#  this  pointer  test  ensures  the  target  memory  matches  the  vnode  template 
vnode  =  Vnode(txt_ptr) 

if  vnode. gettypeO  ==  -1  or  vnode. getname()  ==  None: 
return  None 

#  return  the  pointer  rather  than  vnode  because  duplicates  will  occur  as  a 

result 

#  of  recursive  calls  in  Vm_object 
return  txt_ptr 

#  Vm_map_entry  -->  Vm_object 
class  Vm_object(Struct): 

TEMPLATES  =  { 

32:{ 

10:{'memq' :('queue_head_t' ,0,8, ' ' ,{'next' :('struct  queue_entry 
*',4,4, 'type  test(vm_object)'), 'prev' :(' struct  queue_entry  *',0,4, 'type 
test(vm_object)')}), 'shadow' :( 'struct  vm_object  *',52,4,'- 
>vm_object(recurse)'), 'pager' :('memory_object_t' ,64,4, '->pager')} 

,  ll:{'memq' :('queue_head_t' ,0,8, ' ' ,{'next' :('struct  queue_entry 
*',4,4, 'type  test(vm_object)'), 'prev' :(' struct  queue_entry  *',0,4, 'type 
test(vm_object)')}), 'shadow' :( 'struct  vm_object  *',52,4,'- 
>vm_object(recurse)'), 'pager' :('memory_object_t' ,64,4, '->pager')} 

}, 

64:  { 

10:{'memq' :('queue_head_t' ,0,16, ' ' ,{'next' :( 'struct  queue_entry 
*',8,8, 'type  test(vm_object)'), 'prev' :(' struct  queue_entry  *',0,8, 'type 
test(vm_object)')}), 'shadow' :( 'struct  vm_object  *',72,8,'- 
>vm_object(recurse)'), 'pager' :('memory_object_t' ,88,8, '->pager')} 

,  ll:{'memq' :('queue_head_t' ,0,16, ' ' ,{'next' :( 'struct  queue_entry 
*',8,8, 'type  test(vm_object)'), 'prev' :(' struct  queue_entry  *',0,8, 'type 
test(vm_object)')}), 'shadow' :( 'struct  vm_object  *',72,8,'- 
>vm_object(recurse)'), 'pager' :('memory_object_t' ,88,8, '->pager')} 

} 


139 


731 

732 

733 

734 

735 

736 

737 

738 

739 

740 

741 

742 

743 

744 

745 

746 

747 

748 

749 

750 

751 

752 

753 

754 

755 

756 

757 

758 

759 

760 

761 

762 

763 

764 

765 

766 

767 

768 

769 

770 

771 

772 

773 

774 

775 

776 

777 

778 

779 


} 

def  _ init _ (self,  addr): 

super(Vm_object,  self) _ init _ (addr) 

self. map  =  None 

#  this  test  determines  wether  self  matches  the  struct  vm_object  template,  or 
the 

#  vm_map  template. 

ptrl  =  unpacktype(self .smem,  self . template['memq'] [4] [' next '] ,  INT) 
ptr2  =  unpacktype(self .smem,  self . template['memq'] [4] [' prev'] ,  INT) 
if  ptrl  ==  0  or  ptr2  ==  0  \ 

or  not(Struct.mem. is_valid_address(ptrl))  \ 
or  not(Struct .mem. is_valid_address(ptr2)) : 

#  on  failure,  create  map  instance  to  be  called  recursively 
self. map  =  Vm_map(addr) 

def  gettxt(self) : 

#  recurse  on  vm_map  type 
if  self. map  !=  None: 

return  self .map. gettxt() 

pager_ptr  =  unpacktype(self . smem,  self .template['pager'] ,  INT) 

#  objects  for  memory-mapped  files  keep  the  pager  in  the  shadow  object  rather 

#  than  the  original,  this  test  determines  which  self  is. 

if  pager_ptr  ==  0  or  not(Struct.mem.is_valid_address(pager_ptr)): 

shadow_ptr  =  unpacktype(self .smem,  self . template[' shadow'] ,  INT) 
if  shadow_ptr  ==  0  or  not(Struct.mem.is_valid_address(shadow_ptr)): 
return  []  #  Vm_map  expects  an  empty  list,  never  None 

#  make  recursive  call  on  shadow  object 
shadow  =  Vm_object(shadow_ptr) 
return  shadow. gettxt() 

#  the  default  case  here  wraps  the  return  in  a  list  for  compatibility  with  the 

#  recursive  map  case. 

pager  =  Vnode_pager(pager_ptr) 

return  [  pager .gettxt()  ]  #  NOTE:  this  may  return  [  None  ]  without  error 

#  Vm_map_entry  -->  Vm_map_entry 

#  Vm_map  -->  Vm_map_entry 

class  Vm_map_entry(Struct) : 

TEMPLATES  =  { 

32:{ 

10: {'links ':(' struct  vm_map_links ' ,0,24, ' ' ,{'prev' :( 'struct  vm_map_entry 
* ' ,0,4, ' ' ) , ' next ' : ( ' struct  vm_map_entry  * ' ,4,4, ' ->vm_map_entry ' )}) , ' object ' : ( ' union 
vm_map_object' ,24,4, ' ->vm_object ' )} 
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,  ll:{'links' :('struct  vm_map_links' ,0,24, ' ' ,{'prev' :('struct  vm_map_entry 
* ' ,0,4, ' ' ) , ' next ' : ( ' struct  vm_map_entry  * ' ,4,4, ' ->vm_map_entry ' )}) , ' object ' : ( ' union 
vm_map_object' ,36,4, ' ->vm_object ' )} 

}, 

64:  { 

10: {'links struct  vm_map_links ' ,0,32, ' ' ,{'prev' :( 'struct  vm_map_entry 
*' ,0,8, ' '), 'next' :('struct  vm_map_entry  *' ,8,8, ' ->vm_map_entry ' )}) , 'object' :('union 
vm_map_object' ,32,8, ' ->vm_object ' )} 

,  ll:{'links' :('struct  vm_map_links' ,0,32, ' ' ,{'prev' :('struct  vm_map_entry 
*' ,0,8, ' '), 'next' :('struct  vm_map_entry  *' ,8,8, ' ->vm_map_entry ' )}) , 'object' :('union 
vm_map_object' ,56,8, ' ->vm_object ' )} 

} 

} 

def  _ init _ (self,  addr): 

super(Vm_map_entry ,  self) _ init _ (addr) 

def  getnext(self) : 

return  unpacktype(self .smem,  self . template[' links '] [4] [' next '] ,  INT) 

def  gettxt(self) : 

vmobject_ptr  =  unpacktype( self .smem,  self .template['object'] ,  INT) 

#  some  entries  lack  an  object,  check  manually  to  prevent  error 
if  vmobject_ptr  ==  0  or  not(Struct.mem.is_valid_address(vmobject_ptr)): 
return  []  #  Vm_map  expects  an  empty  list,  never  None 

vm_object  =  Vm_object(vmobject_ptr) 
return  vm_object.gettxt() 

#  Vm_object  -->  Vm_map 

#  Task  -->  Vm_map 

class  Vm_map(Struct) : 

TEMPLATES  =  { 

32:{ 

10:{'hdr' :(' struct  vm_map_header ' ,12,32, '' ,{'l inks' :(' struct 
vm_map_links ' ,12,24, ' ' ,{'prev' :('struct  vm_map_entry  *' ,12,4, ' '), 'next' :('struct 
vm_map_entry  * ' , 16,4, ' ->vm_map_entry ' )}) , ' nentries ' : ( ' int ' ,36,4, ' no.  nodes ' )})} 

,  11 :{' hdr ':(' struct  vm_map_header' ,12,44, '' ,{'links' :('struct 
vm_map_links ' ,12,24, ' ' ,{'prev' :('struct  vm_map_entry  *' ,12,4, ' '), 'next' :('struct 
vm_map_entry  *' ,16,4, ' ->vm_map_entry ' )}) , 'nentries' :('int' ,36,4, 'no.  nodes')})} 

}, 

64:  { 

10: {'hdr' :(' struct  vm_map_header ' ,16,40, '' ,{'l inks' :(' struct 
vm_map_links ' ,16,32, ' ' ,{'prev' :('struct  vm_map_entry  *'  ,16,8, ' '), 'next' :('struct 
vm_map_entry  * ' , 24,8 , ' ->vm_map_entry ' )}) , ' nentries ' : ( ' int ' ,48,4, ' no.  nodes ' )})} 

,  ll:{'hdr' :('struct  vm_map_header' ,16,56, '' ,{'links' :('struct 
vm_map_links ' ,16,32, ' ' ,{'prev' :('struct  vm_map_entry  *' ,16,8, ' '), 'next' :('struct 
vm_map_entry  * ' , 24,8 , ' ->vm_map_entry ' )}) , ' nentries ' : ( ' int ' ,48,4, ' no.  nodes ' )})} 

} 

} 
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def  _ init _ (self,  addr): 

super(Vm_map ,  self) _ init _ (addr) 

def  gettxt(self) : 

vmmapentry_ptr  =  unpacktype(self .smem, 
self .template['hdr'] [4] ['links '] [4] ['next'] ,  INT) 

nentries  =  unpacktype( self .smem,  self . template[' hdr '] [4] [' nentries '] ,  INT) 
ret_ptrs  =  [] 

#  iterate  over  map  entries  in  the  linked-list  and  collect  any  backing  vnode 

ptrs 

for  i  in  xrange(nentries) : 

if  self . validaddr(vmmapentry_ptr) : 

vm_map_entry  =  Vm_map_entry(vmmapentry_ptr) 
txt_ptrs  =  vm_map_entry .gettxtO 

for  txt_ptr  in  txt_ptrs: 

#  filter  duplicates  and  check  for  null  returns 
if  txt_ptr  !=  None  and  not(txt_ptr  in  ret_ptrs): 
ret_ptrs . append(txt_ptr) 

vmmapentry_ptr  =  vm_map_entry . getnext() 

#  unique  list  of  verified  vnode  pointers 
return  ret_ptrs 

#  Proc  -->  Task 
class  Task(Struct) : 

TEMPLATES  =  { 

32:{ 

10: { 'map ' : ( ' vm_map_t ' , 24,4, ' ->vm_map ' )} 

,  11: {'map' :('vm_map_t' ,20,4, '->vm_map')} 

}, 

64:  { 

10: { 'map ' : ( ' vm_map_t ' ,40,8 , ' ->vm_map ' ) ,}  #  NOTE:  10.6x64  offset  for  vm_map 
edited  manually  36  -->  40 

,  11 : { 'map ' : ( ' vm_map_t ' ,32 ,8 , ' ->vm_map ' )} #  NOTE:  10.7x64  offset  for  vm_map 
edited  manually  28  -->  32 
} 

} 

def  _ init _ (self,  addr): 

super(Task,  self) _ init _ (addr) 

def  gettxt(self) : 

vmmap_ptr  =  unpacktype(self . smem,  self .template['map'] ,  INT) 
if  self . validaddr(vmmap_ptr) : 
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vm_map  =  Vm_map(vmmap_ptr) 
return  vm_map.gettxt() 


return  None 

#  Pgrp  -->  Session 
class  Session(Struct): 

TEMPLATES  =  { 

32:{ 

10 : { ' s_login ' : ( ' char [] ' , 28 , 255 , ' USER ' )} 

,  11 : { ' s_login ' : C ' char [] ' , 28 , 255 , ' USER ' )} 

}, 

64:  { 

10 : { ' s_login ' : ( ' char [] ' , 48 , 255 , ' USER ' )} 

,  ll:{'s_login' :('char[] ' ,48,255, 'USER')} 

} 

} 

def  _ init _ (self,  addr): 

super(Session,  self) _ init _ (addr) 

def  getuser(self) : 

return  unpacktype(self .smem,  self . template[' s_login '] ,  STR).split('\x00' , 
l)[0].strip('\x00') 

#  Proc  -->  Pgrp 
class  Pgrp(Struct) : 

TEMPLATES  =  { 

32:{ 

10:{'pg_session' :('struct  session  *' ,12,4, '->session')} 

,  ll:{'pg_session' :('struct  session  *' ,12,4, '->session')} 

}, 

64:  { 

10:{'pg_session' :('struct  session  *' ,24,8, '->session')} 

,  ll:{'pg_session' :('struct  session  *' ,24,8, '->session')} 

} 

} 

def  _ init _ (self,  addr): 

super(Pgrp,  self) _ init _ (addr) 

#  skipped  the  full  validator  here  because  pg_session  is  the  only  pointer/target 
def  getuser(self) : 

session_ptr  =  unpacktype(self . smem,  self .template['pg_session'] ,  INT) 

if  self . validaddr(session_ptr) : 

session  =  Session(session_ptr) 
return  session. getuser() 

return  None 
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#  _kernproc  -->  Proc 
class  Proc(Struct) : 


TEMPLATES  =  { 

32:{ 

10:{'p_list' :('LIST_ENTRY(proc)' ,0,8, ' ' ,{'le_next' :('struct  proc 
*' ,0,4, ' '), 'le_prev' :('struct  proc  **',4,4,'- 

>next')}), 'p_pid' :('pid_t' ,8,4, 'PID'), 'task' :('void  *' ,12,4, '->task'), 'p_fd' :( 'struct 
filedesc  *' ,104,4, '->filedesc'), 'p_textvp' :('struct  vnode  *',388,4,'- 
>proc(exe)'), 'p_comm' :('char[] ' ,420,17, 'COMMAND'), 'p_pgrp' :( 'struct  pgrp  *' ,472,4, '- 
>pgr’P')} 

,  ll:{'p_list' :('LIST_ENTRY(proc)' ,0,8, ' ' ,{'le_next' :('struct  proc 
*' ,0,4, ' '), 'le_prev' :('struct  proc  **',4,4,'- 

>next')}), 'p_pid' :('pid_t' ,8,4, 'PID'), 'task' :C'void  *' ,12,4, '->task'), 'p_fd' :( 'struct 
filedesc  *' ,128,4, '->filedesc'), 'p_textvp' :('struct  vnode  *',412,4,'- 
>proc(exe)'), 'p_comm' :('char[] ' ,444,17, 'COMMAND'), 'p_pgrp' :( 'struct  pgrp  *' ,496,4, '- 
>pgr’P')} 

}, 

64:  { 

10:{'p_list' :('LIST_ENTRY(proc)' ,0,16, ' ' ,{'le_next' :(' struct  proc 
*' ,0,8, ' '), 'le_prev' :('struct  proc  **',8,8,'- 

>next')}), 'p_pid' :('pid_t' ,16,4, 'PID'), 'task' :(' void  *', 24,8 ,' ->task' ),' p_fd ':(' struct 
filedesc  *' ,200,8, '->filedesc'), 'p_textvp' :('struct  vnode  *',664,8,'- 
>proc(exe)'), 'p_comm' :('char[] ' ,700,17, 'COMMAND'), 'p_pgrp' :( 'struct  pgrp  *' ,752,8, '- 
>pgr’P')} 

,  ll:{'p_list' :('LIST_ENTRY(proc)' ,0,16, ' ' ,{'le_next' :(' struct  proc 
*' ,0,8, ' '), 'le_prev' :('struct  proc  **',8,8,'- 

>next')}), 'p_pid' :('pid_t' ,16,4, 'PID'), 'task' :(' void  *', 24,8 ,' ->task' ),' p_fd ':(' struct 
filedesc  *' ,216,8, '->filedesc'), 'p_textvp' :('struct  vnode  *',680,8,'- 
>proc(exe)'), 'p_comm' :('char[] ' ,716,17, 'COMMAND'), 'p_pgrp' :( 'struct  pgrp  *' ,768,8, '- 
>pgr’P')} 

} 

} 

head  =  None 


def  _ init _ (self,  addr): 

superfProc,  self) _ init _ (addr) 

if  Proc. head  ==  None: 

Proc. head  =  addr 


self .self_ptr 

=  addr 

to 

self .filedesc_ptr 

=  None 

self .exe_ptr 

=  None 

self .pgrp_ptr 

=  None 

self .pid 

=  -1 

#  store  this  for  cycle  detection  by 


def  next(self): 

nxt_proc  =  unpacktype(self .smem,  Proc. template['p_list '] [4] [' le_prev'] ,  INT) 
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if  nxt_proc  ==  Proc.head: 

stderr.writeC'ERROR  %s.%s  encountered  a  circular  listAn" 

%(self _ class _ name _ ,  sys ._getframe() .f_code. co_name)) 

return  None 

elif  nxt_proc  !=  0  and  Struct. mem. is_valid_address(nxt_proc): 
return  Proc(nxt_proc) 

return  None 

#  this  method  has  evolved  to  check  ALL  requisite  proc  structure  pointers 
def  valid(self): 

#  check  *p_fd 

filedesc_ptr  =  unpacktype(self .smem,  self .template['p_fd'] ,  INT) 
if  filedesc_ptr  ==  0  or  not(Struct.mem.is_valid_address(filedesc_ptr)): 
return  False 

#  check  *p_textvp 

exe_ptr  =  unpacktype(self . smem,  self .template['p_textvp'] ,  INT) 
if  exe_ptr  ==  0  or  not(Struct.mem.is_valid_address(exe_ptr)): 
return  False 


#  check  *p_pgrp 

pgrp_ptr  =  unpacktype(self .smem,  self .template['p_pgrp'] ,  INT) 
if  pgrp_ptr  ==  0  or  not(Struct.mem.is_valid_address(pgrp_ptr)): 
return  False 

self .filedesc_ptr  =  filedesc_ptr 

self.exe_ptr  =  exe_ptr 

self .pgrp_ptr  =  pgrp_ptr 

return  True 


def  setpid(self,  pid): 

self.pid  =  unpacktype(self .smem,  Proc.template['p_pid'] ,  INT) 


INT) 


while  self.pid  !=  pid: 

nxt_proc  =  unpacktype(self .smem,  Proc. template[' p_list '] [4] ['le_prev'] , 


if  nxt_proc  ==  Proc.head: 

Stderr.writeC'ERROR  %s.%s  encountered  a  circular  list.Xn" 

%(self _ class _ name _ ,  sys ._getframe() .f_code. co_name)) 

return  False 

elif  nxt_proc  !=  0  and  Struct. mem. is_valid_address(nxt_proc) : 
self. smem  =  Struct. mem. read(nxt_proc,  Proc.ssize); 
self.pid  =  unpacktype(self . smem,  Proc.template['p_pid'] ,  INT) 

else: 

return  False 

filedesc_ptr  =  unpacktype(self .smem,  self .template['p_fd'] ,  INT) 
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if  filedesc_ptr  ==  0: 

print  "\nPID:  %d  (%s)  has  no  open  files."  %(pid,  self . getcmdO) 
sys.exitO 

if  not(Struct.mem. is_valid_address(filedesc_ptr)) : 

print  "\nPID:  %d  (%s)  has  an  invalid  file  descriptor."  %(pid, 

self  .getcmdO) 

sys.exitO 

if  not  self.validC): 

print  "\tPID:  %d  appears  in  the  in  process  list,  but  is  not  compatible 
with  Isof . "  %pid 

sys.exitO 

return  True 

def  getfd(self): 

return  self . filedesc_ptr 

def  getpid(self): 

if  self.pid  <  0: 

return  unpacktype(self .smem,  Proc.template['p_pid'] ,  INT) 
return  self.pid 

def  getcmd(self): 

return  unpacktype(self .smem,  self .template['p_comm']  ,  STR) . split( '\x00' , 
l)[0].replace('  ',  '\\x20').strip('\x00') 

def  getuser(self) : 

pgrp  =  PgrpCself .pgrp_ptr) 
return  pgrp.getuserO 

def  gettxt(self) : 

task_ptr  =  unpacktype(self .smem,  self .template['task'] ,  INT) 
task  =  Task(task_ptr) 
txt_ptrs  =  task.gettxtO 

if  not(self . exe_ptr  in  txt_ptrs): 
txt_ptrs . append(self . exe_ptr) 

return  txt_ptrs 

###################################  PRIVATE  FUNCTIONS  #################################### 

#  given  a  validated  proc  stucture,  return  a  list  of  open  files 
def  getfilelistbyproc(proc): 

filedesc  =  Filedesc(proc.getfdO) 
fglobs  =  filedesc. getfglobsO 
filelist  =  [] 

if  fglobs  ==  None: 
return  [] 
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cwd  =  Vnode(filedesc.getcwd()) 
if  cwd: 

filelist.appendC  (proc.getcmd(),  proc.getpid(),  proc.getuser(),  "cwd  ", 

cwd.gettypeO,  cwd.getdev(),  cwd.getoff(-l),  cwd.getnode(),  cwd.getpath()) 

) 

txt_ptrs  =  proc.gettxtO 
for  txt_ptr  in  txt_ptrs: 
txt  =  Vnode(txt_ptr) 

filelist.appendC  (proc.getcmdC),  proc.getpid(),  proc.getuser(),  "txt  ", 

txt.gettypeO,  txt.getdev(),  txt.getoff(-l),  txt.getnode(),  txt.getpath()) 

) 

#  iterate  over  fileglob  structures,  note:  items()  is  unsorted  by  default 
for  fd,  fglob  in  sorted(fglobs . items()) : 

#  this  has  been  observed  as  an  invalid  pointer  even  when  fileproc  is  not 
if  fglob  ==  0  or  not  Struct. mem. is_valid_address(fglob) : 

continue 

fileglob  =  Fileglob(fglob) 

#  full  support  for  VNODE  (1)  only,  otherwise,  just  print  ftype  for  verbose 
ftype  =  fileglob. gettypeC) 

#  exclude  file  if  type  cannot  be  resolved 
if  ftype  ==  -1: 

continue 

if  ftype  !=  'VNODE': 
if  Struct. verb: 

filelist.appendC  Cpi^oc.getcmdC),  proc.getpidC),  proc.getuserC), 
fileglob.getmodeCfd),  ftype,  -1,  -1,  -1,  -1) 

) 

continue 

vnode_ptr  =  fileglob. getdataC) 
if  vnode_ptr  ==  None: 
continue 

vnode  =  VnodeCvnode_ptr) 

filelist.appendC  Cpi^oc.getcmdC),  proc.getpidC),  proc.getuserC), 
fileglob.getmodeCfd),  vnode. gettypeC),  vnode. getdevC), 
vnode .  getof f Cf ileglob .  getof f O) ,  vnode . getnodeC) ,  vnode .  getpathO) 

) 

return  filelist 

####################################  PUBLIC  FUNCTIONS  #################################### 

#  build  list  of  processes  with  open  files,  and  return  the  aggregate  listing 
def  getfilelistCmem,  arch,  kvers,  proc_head,  pid,  vflag): 
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Struct. mem 
Struct. arch 
Struct. kvers 
Struct. verb 


=  mem 
=  arch 
=  kvers 

=  bool(vflag) 


proc  =  Proc(proc_head) 
if  pid  >  -1: 

if  proc.setpid(pid):  #  returns  True  on  success 
return  getfilelistbyproc(proc) 
print  "\tPID:  %d  not  found  in  process  list."  %pid 
sys.exitC) 


ptr_list  =  []  #  this  list  catches  cycles  in  the  linked  list  (known  to  occur) 

proclist  =  [] 
while  proc: 


if  proc. self_ptr  in  ptr_list:  #  test  for  cycle 

stderr .writeC'ERROR  getfilelist() :  proc  linked-list  cycles,  results  may  be 

incomplete. \n") 

break 

ptr_list . append(proc . self_ptr) 


if  proc.validC): 

proclist .append(proc) 
proc  =  proc.nextC) 


fullfilelisting  =  [] 
for  proc  in  proclist: 

fullfilelisting  +=  getfilelistbyproc(proc) 
return  fullfilelisting 


#  given  the  output  of  getfilelist() ,  build  a  string  matrix  as  i 
def  printfilelist(filelist) : 

headerlist  =  ["COMMAND",  "PID",  "USER",  "  FD  ",  "TYPE", 
"NODE",  "NAME"] 

contentlist  =  [] 


nput  to  columnprintO 
"DEVICE",  "SIZE/OFF", 


for  file  in  filelist: 

line  =  ["%s"  %file[0]] 
line.append("%d"  %file[l]) 
line.append("%s"  %file[2]) 
line.append("%s"  %file[3]) 
line.append("%s"  %file[4]) 
line.append("%s"  %file[5]) 
line.append("%s"  %file[6]) 
line.append("%d"  %file[7]) 
line.append("%s"  %file[8]) 
contentlist. append(line) 

#columnprint(headerlist ,  contentlist) 
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#  use  optional  max  size  list  here  to  match  default  Isof  output,  otherwise  specify 

#  Isof  +c  0  on  the  command  line  to  print  full  name  of  commands 
mszlist  =  [9,  -1,  -1,  -1,  -1,  -1,  -1,  -1,  -1] 
columnprint(headerlist,  contentlist,  mszlist) 
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